Memory distribution resolution for programs and processes

Each process in a multitasking operating system runs in one of its own memory sandbox. This sandbox is the virtual address space, which is always a 4GB memory address block in 32-bit mode. These virtual addresses are mapped to physical memory through page tables (page table), which are maintained by the operating system and referenced by the processor. Each process has a page table of its own, but there is one more. As long as the virtual address is enabled, it will be used for all software running on this machine, including the kernel itself. Therefore, part of the virtual address must be reserved for kernel use:

This does not mean that the kernel uses so much physical memory, only that it can dictate such a large address space, which can be mapped to physical memory as required by the kernel. Kernel space has a higher privilege level (ring 2 or less) in the page table, so as long as the user-state program attempts to access the pages, it causes a page fault (page fault). In Linux, kernel space is persisted and mapped to the same physical memory in all processes. Kernel code and data are always addressable and ready to handle interrupts and system calls. In contrast, the mapping of user-mode address spaces varies with process switching:

The blue area represents the virtual address mapped to physical memory, while the white area represents the unmapped part. In the example above, Firefox uses a considerable amount of virtual address space, because it is a legendary memory-hungry large. Each stripe in the address space corresponds to a different memory segment (memory segment), such as heaps, stacks, and so on. Remember, these segments are simply memory address ranges that have nothing to do with the Intel processor segment. Anyway, here is the standard memory segment layout for a Linux process:

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/OS/unix/

When the computer is happy, safe, lovely and normal, the starting virtual address of almost every segment of each process is exactly the same as the previous one, which opens the door to the remote exploit program security vulnerabilities. An excavation process often needs to refer to the absolute memory address: Stack address, library function address, and so on. Remote attackers must rely on the consistency of the address space layout to grope for these addresses. If you let them guess, someone will get the whole. Therefore, the random arrangement of address space is becoming popular. Linux disrupts the layout by adding random offsets to the stack, memory-mapped segments, and the starting address of the heap. Unfortunately, the 32-bit address space is quite compact, leaving little room for randomization, weakening the effect of this technique.

The topmost segment in the process address space is the stack, which is used by most programming languages to store local variables and function parameters. Calling a method or function pushes a new stack frame into the stack. The stack is cleaned up when the function returns. Perhaps because the data is strictly in the order of LIFO, this simple design means that you don't have to use complex data structures to track stack content, just a simple pointer to the top of the stack. Therefore, the pressure stack (pushing) and the retreat stack (popping) process is very rapid and accurate. In addition, continuous reuse of stack space helps to keep active stack memory in the CPU cache, speeding access. Each thread in the process has its own stack.

By constantly pressing data into the stack, the memory area of the stack is depleted by exceeding its capacity. This triggers a page fault (page fault) and is processed by Linux Expand_stack (), which calls Acct_stack_growth () to check if there is a suitable place for stack growth. If the stack is smaller than rlimit_stack (usually 8MB), then the stack will normally be lengthened, the program continues to run happily, and it doesn't feel like anything is going on. This is a general mechanism for extending the stack to the desired size. However, if the maximum stack space size is reached, the stack overflows (stack overflow), and the program receives a segment error (segmentation Fault). When the mapped stack area expands to the desired size, it does not shrink back even if the stack is not full. It's like the federal budget, it's always growing.