6

In this answer author states: With the 64-bit x86_64 kernel, a 32-bit process can use the entire 4GB address space, except for a couple pages (8KB) at the end of the 4GB address space which are managed by the kernel.

What is the purpose of this kernel-managed memory? Shouldn’t it be in the kernel space, to prevent accidental corruption by the user?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
pbp
  • 1,461
  • 17
  • 28

2 Answers2

7

Citing the kernel source: “Kernel pointers have redundant information, so we can use a scheme where we can return either an error code or a [...] pointer with the same return value.”

The values -1..-4095 (mapping to 0xfffff000–0xffffffff in 32-bit mode) are reserved for kernel-level errno values. The other 4KB from 0xffffe000–0xffffefff are held free for the vsyscall vdso magic page, but since the vdso page is relocatable since many moons, this area remains potentially unpopulated, that is to say, the [stack] entry in /proc/*/maps ends at 0xffffdfff always regardless of whether [vdso] is mapped at 0xffffe000 or elsewhere.

jørgensen
  • 10,149
  • 2
  • 20
  • 27
  • 1
    `-4095 .. -1` is `0xfffff001 .. 0xffffffff`. `0xfffff000` is `-4096`, not `-4095`, so it's a valid non-error return value from mmap. ([mmaping that page doesn't actually work](https://stackoverflow.com/questions/47712502/why-cant-i-mmapmap-fixed-the-highest-virtual-page-in-a-32-bit-linux-process-o), but I'm not convinced that's the reason, unless there's a hidden VMA that reserves the top page so the kernel doesn't have to worry about user-space passing them as args to `read` or something.) – Peter Cordes Dec 10 '17 at 19:12
2

Some kernel memory can be inside the application user-space address space, and be sort-of mmap-ed with PROT_NONE. Some address space would then be used, but without being accessible by the program (so no corruption is possible).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547