The Virtual Address Space

A virtual address is not a location; it is a key. The CPU splits it into a virtual page number (the high bits) and an offset within the page (the low 12 bits for 4 kB pages), looks the page number up in the current process’s page table, and gets a physical frame number; frame number plus the unchanged offset is the address that goes to the memory controller. Process A’s table maps virtual page 1 (address 0x1000) to frame 81; process B’s maps its page 1 to frame 12. The same key, two dictionaries, two values. Neither table contains the other’s frame, so neither process can produce an address that reaches it — not by arithmetic, not by guessing, not by a bug.

Which table is current is decided by one register that the kernel writes at every context switch (Context Switching): CR3 on x86-64, TTBR0_EL1 on ARM64. From the CPU’s point of view "which process is running" *is* "which table is loaded"; there is no other notion of process identity in the memory system.

The kernel does not track a process’s memory one page at a time; it keeps a list of regions (virtual memory areas, VMAs, on Linux) each with a start, an end, permissions and a backing: the executable’s code, its data, the heap, each shared library’s code and data, thread stacks, anonymous mmap regions, memory-mapped files, and the main stack. Page-table entries are created from these regions lazily, on first touch. /proc/<pid>/maps prints the list, and reading it is the fastest way to understand a process’s memory.

Note the addresses. The binary is at 0x55… and the libraries and stack at 0x7f… — randomised per run by ASLR within those ranges — and the heap starts right after the binary’s data. Between the regions are gaps: unmapped addresses whose page-table entries do not exist, where any access is a segfault. On a 64-bit process the gaps are the overwhelming majority of the space.

Every process’s page table also maps the kernel: its code, its data, its view of all physical memory. Those entries are marked supervisor-only, so a user-mode access to them faults, but they are there — which is why a system call or interrupt can switch into kernel mode without switching page tables, and why the kernel can read your buffer in write() with an ordinary load. Conventionally the address space is split in half: user addresses have their top bits clear and kernel addresses have them set, so on x86-64 Linux user space is 0x0000_0000_0000_0000–0x0000_7fff_ffff_ffff and kernel space is 0xffff_8000_0000_0000 upwards. Windows uses the same halves; 32-bit systems used a 3 GB / 1 GB or 2 GB / 2 GB split.

The Meltdown vulnerability (2018) showed that speculative execution could leak kernel data through those mapped-but-protected entries. The mitigation, kernel page-table isolation (KPTI on Linux, KVA Shadow on Windows), gives each process two tables — one with the full kernel for kernel mode, one with only the entry trampolines for user mode — and switches between them on every syscall and interrupt. That is the page-table switch per syscall mentioned in System Calls, and it is why PCID support suddenly mattered for syscall-heavy workloads.

A 64-bit register can hold 2⁶⁴ addresses, but no CPU implements that many: page tables for a 64-bit space would be six levels deep and the extra bits buy nothing. x86-64 and ARM64 implement 48-bit virtual addresses — 256 TB, split into 128 TB of user space and 128 TB of kernel space — with four levels of page table (Page Tables). The unused 16 bits must be a copy of bit 47 (a canonical address); an address like 0x0001_2345_6789_abcd is non-canonical and faults with a general protection error rather than a page fault, which is how JavaScript engines and other runtimes get away with pointer tagging: stuffing type bits into the top of a pointer and masking them off before use.

Intel’s 5-level paging (Ice Lake and later; Linux enables it on demand) extends this to 57 bits and 128 PB, for machines with many terabytes of RAM and for databases that want to map everything. Physical addresses are separately limited — typically 46–52 bits — and the two limits are independent: a process on a 16 GB laptop has 128 TB of virtual space, nearly all of it holes.