Today we’ll be talking about the anatomy of a process, as well as the scheduling of execution for for a Userpace Process on the Linux Operating System.
Credit for the following 2 diagrams go to The Linux Documenation Project https://tldp.org
In this first Diagram we see the file layout for a process
In this second diagram we see where things are layed out within virtual memory for a process. If you’ll notice memory is broken up into the code segement and data segment.
CODE SEGMENT
The idea here is the info you aren’t going to change like the algorithm being executed goes in the code segment and it is read only.,
DATA SEGMENT (ALSO CALLED TEXT SEGMENT)
Data will change at runtime and is writable. Seems simple enough, but there is one additional thing I just want to throw in while we’re on this topic to deepen your understanding from a security point of view.
SECURITY IMPLICATIONS: Code should never be allowed to run from the data segment.
PROBLEM:
Here we’ll discuss an example of a data segment vulnerability called a buffer overflow. If an attacker can overflow a buffer beyond what is addressable and basically write to memory it shouldn’t be able to, code injection is possible within the data segment. If the memory is not protected the code injection is successful, and a jump programmed into memory can cause the malicious code to execute (not from code segment, where code should be running from, but from the data segment). This malicious code is referred to as “shellcode”.
If the memory region IS protected, the write attempt will fail and result in a SIGSEGV signal getting generated and the process being closed/crashing. SIGSEGV is an abbreviation for “Segmentation Violation” That generally means the process is trying to write to a segment of memory that it either doesn’t own, or is marked as read only.
SOLUTION:
1.) Write better code. Don’t leave buffers vulnerable to overflow. Do this by Sanitizing and verifying input content, type, size, and format.
2.) NX bit. The NO EXECUTE bit in modern architectures, if enabled says basically “I don’t care what your instructions say, this section of memory is marked as not executable, so I’m not running the code that’s there.”
PROCESS PERFORMANCE
PAGE FAULTS and their relation to working set size.
Credit for this diagram goes to https://GeeksforGeeks.org
Someone else has explained this process better already, so I’ll just link you to that explanation. https://www.geeksforgeeks.org/page-fault-handling-in-operating-system/
The moral of the story is page faults, too many at least, are bad. It means the process is basically getting slowed down and/or context switched out because of memory I/O and disk I/O to get access to the data. If you have a high number of page faults it could mean there are not enough frames allocated to the process (process doesn’t have enough physical memory allocated).
This number of pages loaded and active in the frames of Physical Memory for a process are referenced with differing terminology based on operating system.
A good article on figuring out what we’ll call “working set size” can be found here on that topic from Stanford. https://web.stanford.edu/~ouster/cgi-bin/cs140-winter12/lecture.php?topic=thrashing
To be clear on the wording used here. A frame is a fixed length block of physical RAM. A page is a fixed length block of virtual memory (ie memory on disk)