Kernel address space mappings with respect to virtual address space – a question based on text by Robert Love

Those limits don't come from Debian or from Linux, they come from the hardware. Different architectures (processor and memory bus) have different limitations.

On current x86-64 PC processors, the MMU allows 48 bits of virtual address space. That means that the address space is limited to 256TB. With one bit to distinguish kernel addresses from userland addresses, that leaves 128TB for a process's address space.

On current x86-64 processors, physical addresses can use up to 48 bits, which means you can have up to 256TB. The limit has progressively risen since the amd64 architecture was introduced (from 40 bits if I recall correctly). Each bit of address space costs some wiring and decoding logic (which makes the processor more expensive, slower and hotter), so hardware manufacturers have an incentive to keep the size down.

Linux only allows physical addresses to go up to 2^46 (so you can only have up to 64TB) because it allows the physical memory to be entirely mapped in kernel space. Remember that there are 48 bits of address space; one bit for kernel/user leaves 47 bits for the kernel address space. Half of that at most addresses physical memory directly, and the other half allows the kernel to map whatever it needs. (Linux can cope with physical memory that can't be mapped in full at the same time, but that introduces additional complexity, so it's only done on platforms where it's require, such as x86-32 with PAE and armv7 with LPAE.)

It's useful for virtual memory to be larger than physical memory for several reasons:

• It lets the kernel map the whole physical memory, and have space left for additional virtual mappings.
• In addition to mappings of physical memory, there are mappings of swap, of files and of device drivers.
• It's useful to have unmapped memory in places: guard pages to catch buffer overflows, large unmapped zones due to ASLR, etc.

The answer depends on whether kernel page-table isolation is enabled (which depends on the architecture and whether it supports KPTI).

Without KPTI, the kernel is fully mapped in each process’ address space, but as mentioned in the diagram, those mappings are inaccessible from user space (barring side-channel leaks).

With KPTI, the kernel page tables are separate from the userspace page tables, and only a minimal set of mappings are left in each process’ address space, as required to allow user space to call into the kernel, and to enable the processor to give control to the kernel when dealing with interrupts or exceptions.

In both cases, all processes have the same mappings for the kernel.

See also LWN’s article on KAISER.