Kernel Virtual Memory – Inside 64-bit Linux Processes

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.

1. The kernel mapping exists primarily for the kernel’s purposes, not user processes’. From the CPU’s perspective, any physical memory address which isn’t mapped as a linear address might as well not exist. But the CPU does need to be able to call into the kernel: to service interrupts, to handle exceptions... It also needs to be able to call into the kernel when a user process issues a system call (there are various ways this can happen so I won’t go into details). On most if not all architectures, this happens without the opportunity to switch page tables — see for example SYSENTER. So at minimum, entry points into the kernel have to be mapped into the current address space at all times.

2. Kernel allocations are dynamic, but the address space isn’t. On 32-bit x86, various splits are available, such as the 3/1 GiB split shown in your diagram; on 64-bit x86, the top half of the address space is reserved for the kernel (see the memory map in the kernel documentation). That split can’t move. (Note that libraries are loaded into user space. Kernel modules are loaded into kernel space, but again that only changes the allocations, not the address space split.)

3. In user mode, there is a single mapping for the kernel, shared across all processes. When a kernel-side page mapping changes, that change is reflected everywhere.

   When KPTI is enabled, the kernel has its own private mappings, which aren’t exposed when running user-space code; so with KPTI there are two mappings, and changes to the kernel-private one won’t be visible to user-space (which is the whole point of KPTI).

   The kernel memory map always maps all the kernel (in kernel mode when running KPTI), but it’s not necessarily one-to-one — on 64-bit x86 for example it includes a full map of physical memory, so all kernel physical addresses are mapped at least twice.