What Is a Virtual Address Space?

When your C program calls malloc() or accesses an array, it uses virtual addresses, not physical RAM addresses. The CPU’s Memory Management Unit (MMU) transparently translates each virtual address to a physical address at run time using a data structure called a page table.

This translation layer gives every process the illusion that it owns the full address range of the CPU. On a 32-bit system that range is 4 GB; on a 64-bit system it is theoretically 16 EB (exabytes). This full range is the Virtual Address Space (VAS) of a process.

The VAS is almost entirely sparse — most addresses are unmapped. Only the regions that are explicitly mapped (text segment, data segment, heap, stack, library mappings, kernel segment) consume actual page-table entries and, when accessed, consume physical RAM.

The Linux Kernel VM Split: User Space vs Kernel Space

Every process VAS on Linux is divided into two halves: user space and kernel space. This is called the VM split (or user:kernel split). The boundary is set at compile time by the kernel configuration parameter PAGE_OFFSET.

The kernel space half is identical in every process VAS. When a process makes a system call or an interrupt fires, the CPU switches from user mode to kernel mode and starts executing kernel code that lives in the upper portion of the same virtual address space. This design avoids a full context switch just to access kernel memory — the kernel segment is always mapped in.

Canonical vs Non-Canonical Addresses on x86-64

With 48-bit addressing on x86-64, only bits 0–47 carry address information. The hardware requires that bits 48–63 be a sign extension of bit 47. This means they must all be 0 (if bit 47 is 0) or all be 1 (if bit 47 is 1). An address satisfying this rule is called a canonical address.

Addresses where bits 48–63 are neither all-0 nor all-1 are non-canonical. The CPU raises a general-protection fault if you try to access a non-canonical address. This is exactly the large unused “hole” in the middle of the 64-bit VAS — it is not wasted; it is a hardware enforcement zone.

The two canonical halves together give each process a total of 256 TB of usable virtual address space — 128 TB for user programs and 128 TB for the kernel. The enormous non-canonical region in between is why we describe the VAS as sparse: almost no addresses in the full 64-bit range are actually valid.

What Lives in the Kernel Segment?

The kernel segment (canonical higher half) holds everything the Linux kernel needs:

• Kernel text & data: The compiled kernel binary — vmlinux — its read-only code and read-write global data.
• Per-process kernel stacks: Every process has a small kernel-mode stack (typically 16 KB on 64-bit systems) used during system calls and interrupts.
• Page tables: The multi-level page tables that translate virtual to physical addresses for all processes.
• Task structures (struct task_struct): The kernel’s process descriptor that tracks state, scheduling, file descriptors, memory maps, and more.
• Kernel modules: Loadable modules (.ko files) are mapped here when inserted with insmod or modprobe.
• Device driver memory: DMA buffers, ioremap regions, and driver-specific allocations.
• vmalloc / vmap region: Virtually-contiguous but physically-discontiguous memory used by the kernel for large allocations.
• Direct physical memory map: On 64-bit kernels, all physical RAM is directly mapped into the kernel segment. This is how the kernel accesses any physical page without needing to map it first.

The Full Process VAS: Every Process Is Unique in User Space, Identical in Kernel Space

This is one of the most important concepts in Linux kernel internals: all processes running on the system share the exact same kernel segment, but each process has its own private user VAS.

Inspecting the VAS of a Running Process

On any Linux system you can view the actual VAS segments of a process through the procfs filesystem. The file /proc/<pid>/maps lists every mapped memory region with its address range, permissions, and backing file.

# Show the VAS of the current shell
cat /proc/self/maps

# Show the VAS of a specific process (replace 1234 with actual PID)
cat /proc/1234/maps

# More readable output using pmap
pmap -x 1234

A typical output line looks like:

55a3b2c00000-55a3b2c02000 r--p 00000000 08:01 1245678  /usr/bin/bash
55a3b2c02000-55a3b2caf000 r-xp 00002000 08:01 1245678  /usr/bin/bash
55a3b2caf000-55a3b2ce4000 r--p 000af000 08:01 1245678  /usr/bin/bash
55a3b2ce4000-55a3b2ce8000 r--p 000e3000 08:01 1245678  /usr/bin/bash
55a3b2ce8000-55a3b2ceb000 rw-p 000e7000 08:01 1245678  /usr/bin/bash
55a3b3a5a000-55a3b3b0d000 rw-p 00000000 00:00 0        [heap]
7f8b1f000000-7f8b1f200000 rw-p 00000000 00:00 0
7ffceb1a4000-7ffceb1c5000 rw-p 00000000 00:00 0        [stack]
7ffceb1e1000-7ffceb1e5000 r--p 00000000 00:00 0        [vvar]
7ffceb1e5000-7ffceb1e7000 r-xp 00000000 00:00 0        [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]

The permission string has the format rwxp: r=read, w=write, x=execute, and p=private (copy-on-write) or s=shared. Notice that the text segment is r-xp (read + execute, no write), the heap is rw-p, and the stack is also rw-p.

Addresses starting with 7f... are in the upper 128 TB canonical lower half (user space) on x86-64. Addresses starting with ffff... belong to the kernel segment and appear only in kernel-mode context — they are not visible in /proc/maps for security reasons.

Changes in Recent Kernels (Linux 5.x / 6.x)

The fundamental VM split concept has been stable for many years, but modern kernels have introduced important refinements:

KPTI: When the Kernel Segment Is No Longer Fully Mapped in User Mode

Before the Meltdown vulnerability (CVE-2017-5754), the full kernel segment was always mapped in every process’s page table even during user-mode execution — it was just protected by the supervisor/user permission bit. Meltdown showed that speculative execution could leak kernel data across this boundary.

KPTI (Kernel Page-Table Isolation) introduced a two-page-table model: a minimal user-mode page table (containing only the kernel trampoline needed to handle system calls) and the full kernel page table. On every context switch between user and kernel mode, the CPU switches between these two page tables. This adds a small performance overhead but closes the Meltdown side-channel.

From a conceptual standpoint, the VM split still exists; the implementation is just more security-conscious now.

Common Mistakes and Misconceptions

• Confusing virtual with physical addresses: The addresses in /proc/maps are all virtual. Two processes can have the same virtual address but they map to completely different physical pages.
• Thinking 64-bit means 16 EB of usable RAM: The VAS is 16 EB on a 64-bit system, but the CPU only implements 48 or 57 address bits. Physical RAM support is much smaller (typically up to a few TB on server platforms).
• Assuming the stack grows up: On x86 and ARM, the user-mode stack grows downward (toward lower addresses). The heap grows upward. This is why they can coexist in the same VAS without a fixed boundary.
• Thinking kernel memory can be swapped: It cannot. Kernel memory is always resident. Only user-space pages participate in page-out to swap.
• Confusing PAGE_OFFSET with a physical address: PAGE_OFFSET is the virtual address where the kernel segment starts. On 32-bit IA-32 with 3:1 split it is 0xC0000000. It is not a physical address.

Best Practices for Kernel and Driver Developers

• Always use copy_to_user() / copy_from_user() when exchanging data between kernel and user space — never dereference a raw user pointer in kernel mode.
• Use access_ok() before accessing user-space pointers to verify the address falls within the user VAS.
• Prefer kmalloc() for small kernel allocations and vmalloc() for large ones that do not need physical contiguity.
• When writing device drivers that use DMA, allocate coherent memory with dma_alloc_coherent() rather than kmalloc() to avoid cache-coherency issues.
• Use IS_ERR() and PTR_ERR() to handle error pointers returned by kernel APIs — a value like -ENOMEM encoded in a pointer looks like a valid kernel-space address but is not.

Frequently Asked Questions