0

From Understanding the Linux Kernel:

Segmentation has been included in 80x86 microprocessors to encourage programmers to split their applications into logically related entities, such as subroutines or global and local data areas. However, Linux uses segmentation in a very limited way. In fact, segmentation and paging are somewhat redundant, because both can be used to separate the physical address spaces of processes: segmentation can assign a different linear address space to each process, while paging can map the same linear address space into different physical address spaces. Linux prefers paging to segmentation for the following reasons:

  • Memory management is simpler when all processes use the same segment register values—that is, when they share the same set of linear addresses.
  • One of the design objectives of Linux is portability to a wide range of architectures; RISC architectures, in particular, have limited support for segmentation.

The 2.6 version of Linux uses segmentation only when required by the 80x86 architecture.

The x86-64 architecture does not use segmentation in long mode (64-bit mode). As the x86 has segments, it is not possible to not use them. Four of the segment registers: CS, SS, DS, and ES are forced to 0, and the limit to 2^64. If so, two questions have been raised:

  • Stack data (stack segment) and heap data (data segment) are mixed together, then pop from the stack and increase the ESP register is not available.
  • How does the operating system know which type of data is (stack or heap) in a specific virtual memory address?
  • How do different programs share the kernel code by sharing memory?
Marco Bonelli
  • 63,369
  • 21
  • 118
  • 128
Tri
  • 113
  • 7
  • 1
    `push` / `pop` work regardless of where ESP is pointing, just like on ARM or other ISAs that never had segmentation. You can allocate a buffer with `mmap` and point ESP into that, and use it as your stack. (That's how pthreads allocates thread stacks for new threads!) The OS doesn't need to know or care how user-space is using a memory region. (Although it does know about the main-thread's stack region so it can magically grow that allocation.) – Peter Cordes Feb 13 '22 at 18:32

1 Answers1

3

Stack data (stack segment) and heap data (data segment) are mixed together, then pop from the stack and increase the ESP register is not available.

As Peter states in the above comment, even though CS, SS, ES and DS are all treated as having zero base, this does not change the behavior of PUSH/POP in any way. It is no different than any other segment descriptor usage really. You could get overlapping segments even in 32-bit multi-segment mode if you point multiple selectors to the same descriptor. The only thing that "changes" in 64-bit mode is that you have a base forced by the CPU, and RSP can be used to point anywhere in addressable memory. PUSH/POP operations will work as usual.

How does the operating system know which type of data is (stack or heap) in a specific virtual memory address?

User-space programs can (and will) move the stack and heap around as they please. The operating system doesn't really need to know where stack and heap are, but it can keep track of those to some extent, assuming the user-space application does everything according to convention, that is uses the stack allocated by the kernel at program startup and the program break as heap.

Using the stack allocated by the kernel at program startup, or a memory area obtained through mmap(2) with MAP_GROWSDOWN, the kernel tries to help by automatically growing the memory area when its size is exceeded (i.e. stack overflow), but this has its limits. Manual MAP_GROWSDOWN mappings are rarely used in practice (see 1, 2, 3, 4). POSIX threads and other more modern implementations use fixed-size mappings for threads.

"Heap" is a pretty abstract concept in modern user-space applications. Linux provides user-space applications with the basic ability to manipulate the program break through brk(2) and sbrk(2), but this is rarely in a 1-to-1 correspondence with what we got used to call "heap" nowadays. So in general the kernel does not know where the heap of an application resides.

How do different programs share the kernel code by sharing memory?

This is simply done through paging. You could say there is one hierarchy of page tables for the kernel and many others for user-space processes (one for each task). When switching to kernel-space (e.g. through a syscall) the kernel changes the value of the CR3 register to make it point to the kernel's page global directory. When switching back to user-space, CR3 is changed back to point to the current process' page global directory before giving control to user-space code.

Marco Bonelli
  • 63,369
  • 21
  • 118
  • 128
  • Thread stacks shouldn't use `MAP_GROWSDOWN`; in fact nothing should use that because the kernel doesn't support it properly/safely. (i.e. doesn't stop other random allocations from getting placed in the way of future growth). Linux thread stacks don't grow, unlike the main thread. There's `MAP_STACK` in case some future ISA ever needs to know that an allocation is a stack, but for now it does nothing because the kernel doesn't need to care except for the main thread's stack. See [Analyzing memory mapping of a process with pmap. \[stack\]](https://stackoverflow.com/a/56920770) – Peter Cordes Feb 13 '22 at 20:01