6c:T446,Before examining Linux-specific layout, we must understand the hardware constraints that shape it. The x86-64 architecture defines a 64-bit virtual address space, but current implementations don't use all 64 bits. **Why 48 bits, not 64?** Modern x86-64 processors implement only **48 bits of virtual address space**, supporting 256 TB of addressable memory. This might seem like an arbitrary limitation, but it reflects practical engineering tradeoffs: 1. **Page table depth**: Each additional bit of address space requires larger page tables. 48 bits already requires 4-level page tables; full 64 bits would require even deeper hierarchies. 2. **Physical memory limits**: No system today has 16 exabytes of RAM. Engineering for the common case saves transistors and power. 3. **Hardware complexity**: Wider address buses increase interconnect complexity and latency. However, newer processors (Intel Ice Lake, AMD Zen 4) support **57-bit virtual addresses** through 5-level paging, expanding the addressable space to 128 PB. Linux supports this via the `CONFIG_X86_5LEVEL` kernel option.6d:T98b,/* * Canonical Address Verification * Demonstrates how to check if an address is canonical on x86-64 */ #include #include #include /* * Check if a 64-bit address is canonical (valid for 48-bit addressing). * * For 48-bit virtual addressing: * - Bits 0-47 contain the actual address * - Bits 48-63 must be sign extensions of bit 47 * - If bit 47 is 0, bits 48-63 must all be 0 (user space) * - If bit 47 is 1, bits 48-63 must all be 1 (kernel space) */ bool is_canonical_address(uint64_t addr) { /* * Shift right by 47 to get the high bits. * For a canonical address, this should yield either: * - 0x00000 (all zeros) for addresses 0x0000000000000000 - 0x00007FFFFFFFFFFF * - 0x1FFFF (all ones) for addresses 0xFFFF800000000000 - 0xFFFFFFFFFFFFFFFF */ uint64_t high_bits = addr >> 47; return (high_bits == 0) || (high_bits == 0x1FFFF); } /* * Determine the address space region for a given address. */ const char* get_address_region(uint64_t addr) { if (!is_canonical_address(addr)) { return "NON-CANONICAL (Invalid - causes #GP fault)"; } /* Bit 47 determines user vs kernel space */ if (addr & (1ULL << 47)) { return "KERNEL SPACE (0xFFFF800000000000 - 0xFFFFFFFFFFFFFFFF)"; } else { return "USER SPACE (0x0000000000000000 - 0x00007FFFFFFFFFFF)"; } } int main() { /* Test addresses demonstrating canonical address rules */ uint64_t test_addresses[] = { 0x0000000000401000, /* Typical code segment */ 0x00007FFF12345678, /* Top of user space (stack region) */ 0x0001000000000000, /* Non-canonical hole (INVALID) */ 0x8000000000000000, /* Non-canonical (INVALID) */ 0xFFFF800000000000, /* Start of kernel space */ 0xFFFFFFFF80000000, /* Kernel text segment */ 0xFFFFFFFFFFFFFFFF, /* Top of kernel space */ }; printf("x86-64 Canonical Address Analysis (48-bit mode) "); printf("================================================ "); for (int i = 0; i < sizeof(test_addresses) / sizeof(test_addresses[0]); i++) { uint64_t addr = test_addresses[i]; printf("Address: 0x%016lX ", addr); printf(" Canonical: %s ", is_canonical_address(addr) ? "YES" : "NO"); printf(" Region: %s ", get_address_region(addr)); } return 0; }6e:T45f,**Understanding each region in depth:** **Text Segment (Code)** The text segment contains the machine code instructions of the program. Key characteristics: - Mapped read-only and executable (RX permissions) - Shared between processes running the same executable - Size fixed at compile time - Starts at a low virtual address (traditionally 0x400000 on x86-64, but randomized with PIE) **Data and BSS Segments** These segments hold global and static variables: - **Data Segment**: Variables explicitly initialized (e.g., `int x = 42;`) - **BSS Segment**: Uninitialized or zero-initialized variables (e.g., `int y;`) - BSS doesn't occupy space in the executable file—the kernel zero-fills it at load time - Both have read-write permissions but are not executable **Heap Region** The heap provides dynamically allocated memory: - Managed by the memory allocator (glibc's malloc, jemalloc, tcmalloc, etc.) - Grows upward (toward higher addresses) via `brk()` or `mmap()` - No inherent size limit, but the kernel may refuse expansion - Large allocations (typically >128KB) use `mmap()` instead of extending the heap6f:T873,/* * Demonstrating Linux Process Memory Layout * Compile: gcc -o memory_layout memory_layout_demo.c * Run: ./memory_layout * Analysis: cat /proc/$(pgrep memory_layout)/maps */ #include #include #include /* Global initialized variable - goes to DATA segment */ int global_initialized = 42; /* Global uninitialized variable - goes to BSS segment */ int global_uninitialized; /* Constant string - goes to read-only DATA (.rodata) */ const char *constant_string = "This string lives in .rodata"; void print_memory_layout() { /* Local variable - goes to STACK */ int stack_variable = 100; /* Dynamic allocation - goes to HEAP */ int *heap_ptr = malloc(1024); /* Large allocation - typically uses mmap instead of heap */ int *mmap_allocation = malloc(1024 * 1024); /* 1 MB */ printf("=== Linux Process Memory Layout Demo === "); printf("TEXT (Code) Segment: "); printf(" main() function: %p ", (void*)main); printf(" print_memory_layout(): %p ", (void*)print_memory_layout); printf("DATA Segment (initialized globals): "); printf(" global_initialized: %p ", (void*)&global_initialized); printf("RODATA Segment (constants): "); printf(" constant_string: %p ", (void*)constant_string); printf("BSS Segment (uninitialized globals): "); printf(" global_uninitialized: %p ", (void*)&global_uninitialized); printf("HEAP Segment (small dynamic allocations): "); printf(" heap_ptr (1KB): %p ", (void*)heap_ptr); printf("MMAP Region (large allocations): "); printf(" mmap_allocation (1MB): %p ", (void*)mmap_allocation); printf("STACK Segment: "); printf(" stack_variable: %p ", (void*)&stack_variable); printf("Process ID: %d ", getpid()); printf("Examine detailed memory map: cat /proc/%d/maps ", getpid()); /* Keep process alive for /proc examination */ printf(" Press Enter to exit... "); getchar(); free(heap_ptr); free(mmap_allocation); } int main() { print_memory_layout(); return 0; }70:T43b,The stack and heap are the two primary regions of dynamic memory in a process. Understanding their fundamentally different growth patterns and limits is essential for diagnosing memory issues. **Stack Characteristics:** - **Growth Direction**: Downward (toward lower addresses) - **Management**: Automatic, compiler-managed via push/pop operations - **Speed**: Extremely fast allocation/deallocation (just adjust stack pointer) - **Default Size Limit**: ~8 MB on most Linux systems (configurable via `ulimit -s`) - **Overflow Behavior**: SIGSEGV (segmentation fault) when limit exceeded - **Thread Consideration**: Each thread gets its own stack (default ~8 MB each) **Heap Characteristics:** - **Growth Direction**: Upward (toward higher addresses), or scattered via mmap - **Management**: Explicit programmer control via malloc/free, new/delete - **Speed**: Slower due to allocator overhead and potential system calls - **Size Limit**: Limited only by available virtual address space and kernel limits - **Failure Mode**: malloc() returns NULL, or OOM killer terminates process71:Ta4b,/* * Stack Limit Demonstration * Shows how to query and understand stack limits on Linux * * Compile: gcc -o stack_limits stack_limits.c */ #include #include #include #include void print_stack_limits() { struct rlimit rl; if (getrlimit(RLIMIT_STACK, &rl) == 0) { printf("Stack Limits: "); printf(" Current (soft) limit: "); if (rl.rlim_cur == RLIM_INFINITY) { printf("unlimited "); } else { printf("%lu KB (%lu MB) ", rl.rlim_cur / 1024, rl.rlim_cur / (1024 * 1024)); } printf(" Maximum (hard) limit: "); if (rl.rlim_max == RLIM_INFINITY) { printf("unlimited "); } else { printf("%lu KB (%lu MB) ", rl.rlim_max / 1024, rl.rlim_max / (1024 * 1024)); } } } void print_address_space_limits() { struct rlimit rl; if (getrlimit(RLIMIT_AS, &rl) == 0) { printf(" Address Space Limits: "); printf(" Current limit: "); if (rl.rlim_cur == RLIM_INFINITY) { printf("unlimited "); } else { printf("%lu GB ", rl.rlim_cur / (1024UL * 1024 * 1024)); } } } void demonstrate_stack_frame() { int local_var = 42; char local_array[1024]; /* 1 KB on stack */ printf(" Stack Frame Analysis: "); printf(" Address of local_var: %p ", (void*)&local_var); printf(" Address of local_array: %p ", (void*)local_array); printf(" Stack frame size ~%ld bytes ", (char*)&local_var - local_array); } /* * Recursive function to demonstrate stack growth * WARNING: This can crash if you remove the depth limit! */ void recursive_depth_test(int depth, void *initial_frame) { int frame_marker; if (depth == 100 || depth == 1000 || depth == 10000) { size_t stack_used = (char*)initial_frame - (char*)&frame_marker; printf(" Depth %5d: Stack used = %zu KB ", depth, stack_used / 1024); } if (depth < 10000) { recursive_depth_test(depth + 1, initial_frame); } } void test_recursive_depth() { int frame_marker; printf(" Recursive Stack Growth: "); recursive_depth_test(1, &frame_marker); } int main() { printf("=== Linux Stack Analysis === "); print_stack_limits(); print_address_space_limits(); demonstrate_stack_frame(); test_recursive_depth(); printf(" Tip: Modify stack limit with 'ulimit -s ' "); return 0; }72:Td1b,# Example /proc/[pid]/maps output for a simple program # Read with: cat /proc/self/maps (or use /proc//maps for another process) # ----------------------------------------------------------- # EXECUTABLE (TEXT, DATA, BSS) # ----------------------------------------------------------- 00400000-00403000 r--p 00000000 fd:01 12582912 /home/user/program 00403000-00405000 r-xp 00003000 fd:01 12582912 /home/user/program 00405000-00406000 r--p 00005000 fd:01 12582912 /home/user/program 00406000-00407000 r--p 00005000 fd:01 12582912 /home/user/program 00407000-00408000 rw-p 00006000 fd:01 12582912 /home/user/program # Key observations: # - r--p (read-only): .rodata, symbol tables # - r-xp (read+execute): .text (code) # - rw-p (read+write): .data, .bss (global variables) # ----------------------------------------------------------- # HEAP (grows upward) # ----------------------------------------------------------- 01a4f000-01a70000 rw-p 00000000 00:00 0 [heap] # - Always rw-p (read+write, private) # - No backing file (device 00:00, inode 0) # - [heap] pseudo-path identifies it # ----------------------------------------------------------- # SHARED LIBRARIES (mmap region) # ----------------------------------------------------------- 7f3a2c000000-7f3a2c021000 rw-p 00000000 00:00 0 7f3a2c021000-7f3a30000000 ---p 00000000 00:00 0 7f3a31200000-7f3a31400000 rw-p 00000000 00:00 0 # libc.so.6 - The C library 7f3a31582000-7f3a315a7000 r--p 00000000 fd:01 1835025 /lib/x86_64-linux-gnu/libc.so.6 7f3a315a7000-7f3a3173c000 r-xp 00025000 fd:01 1835025 /lib/x86_64-linux-gnu/libc.so.6 7f3a3173c000-7f3a31794000 r--p 001ba000 fd:01 1835025 /lib/x86_64-linux-gnu/libc.so.6 7f3a31794000-7f3a31798000 r--p 00211000 fd:01 1835025 /lib/x86_64-linux-gnu/libc.so.6 7f3a31798000-7f3a3179a000 rw-p 00215000 fd:01 1835025 /lib/x86_64-linux-gnu/libc.so.6 # The dynamic linker (ld-linux.so) 7f3a317b7000-7f3a317b9000 r--p 00000000 fd:01 1835013 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7f3a317b9000-7f3a317e3000 r-xp 00002000 fd:01 1835013 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7f3a317e3000-7f3a317ed000 r--p 0002c000 fd:01 1835013 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7f3a317ee000-7f3a317f0000 r--p 00036000 fd:01 1835013 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7f3a317f0000-7f3a317f2000 rw-p 00038000 fd:01 1835013 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 # ----------------------------------------------------------- # KERNEL-PROVIDED MAPPINGS # ----------------------------------------------------------- 7f3a317f2000-7f3a317f5000 rw-p 00000000 00:00 0 7fff2bc97000-7fff2bcb8000 rw-p 00000000 00:00 0 [stack] 7fff2bd0c000-7fff2bd10000 r--p 00000000 00:00 0 [vvar] 7fff2bd10000-7fff2bd12000 r-xp 00000000 00:00 0 [vdso] # [stack] - The main thread's stack # [vvar] - Kernel variables (time, etc.) shared read-only # [vdso] - Virtual DSO for fast system calls without kernel entry # ----------------------------------------------------------- # VSYSCALL (legacy, x86-64 specific) # ----------------------------------------------------------- ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] # Note: This is in the KERNEL address range! # It's a special compatibility page for legacy vsyscall users. # Modern code uses vDSO instead.73:T64a,#!/bin/bash # ASLR Demonstration Script # Shows how addresses change across executions echo "=== ASLR Demonstration ===" echo "" # Check current ASLR setting echo "Current ASLR setting:" cat /proc/sys/kernel/randomize_va_space echo " 0 = ASLR disabled" echo " 1 = Stack/libraries randomized" echo " 2 = Stack/libraries/heap randomized (full ASLR)" echo "" # Create a simple test program cat > /tmp/aslr_test.c << 'EOF' #include #include int global_var = 42; int main() { int stack_var = 1; int *heap_var = malloc(sizeof(int)); printf("Executable: %p ", (void*)main); printf("Stack: %p ", (void*)&stack_var); printf("Heap: %p ", (void*)heap_var); printf("Global: %p ", (void*)&global_var); printf("libc: %p ", (void*)printf); free(heap_var); return 0; } EOF # Compile as PIE (default on modern systems) gcc -pie -o /tmp/aslr_test /tmp/aslr_test.c 2>/dev/null echo "Running same program 5 times (observe address randomization):" echo "" for i in {1..5}; do echo "--- Run $i ---" /tmp/aslr_test echo "" done echo "Notice how addresses change between runs!" echo "The relative positions remain similar, but base addresses differ." echo "" # Demonstrate disabling ASLR for a single process echo "Running with ASLR disabled (setarch -R):" echo "--- Run with ASLR off ---" setarch $(uname -m) -R /tmp/aslr_test echo "" echo "--- Another run with ASLR off ---" setarch $(uname -m) -R /tmp/aslr_test echo "" echo "Addresses are now identical between runs." # Cleanup rm -f /tmp/aslr_test /tmp/aslr_test.c64:{"json":{"id":"seed_7f7a761394602e2daaa1836af2ab4311","slug":"os-memory-management-in-practice-linux-memory-management","category":"Operating Systems","topic":"Linux Memory Management","title":"Linux Memory Management","description":"Master the internals of Linux memory management, from virtual address space layout and x86-64 page tables to kernel/user memory organization and memory zones. Understand how production Linux systems manage physical and virtual memory.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_13969490d376654b600ed8a0a2e20670","title":"Virtual Memory Layout","order":0,"content":[{"id":"opening-hook","title":"The Blueprint of Memory","content":[{"data":{"content":"Every process running on a Linux system believes it has exclusive access to a vast, contiguous address space spanning terabytes of memory. This illusion—one of the most elegant abstractions in systems programming—is orchestrated by the virtual memory system. But how exactly does Linux organize this virtual address space? What determines where your stack lives, where the heap grows, and where the kernel resides?\n\nUnderstanding the **virtual memory layout** is foundational for systems programmers, kernel developers, security researchers, and anyone who needs to debug memory corruption, optimize performance, or understand low-level system behavior. This isn't abstract theory—it's the actual memory map you'll encounter when debugging with GDB, analyzing crash dumps, or writing exploit mitigations."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Master","content":"By completing this page, you will understand the complete virtual address space layout on x86-64 Linux: the 48-bit addressing scheme, canonical address forms, the kernel/user space split at the 128TB boundary, and the precise organization of text, data, BSS, heap, shared libraries, and stack regions. You'll be able to read and interpret `/proc/[pid]/maps` with expert-level understanding.","variant":"info"},"type":"callout"}]},{"id":"x86-64-virtual-address-space","title":"The x86-64 Virtual Address Space","content":[{"data":{"content":"$6c"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Canonical Addresses","content":"The x86-64 architecture enforces 'canonical' addresses. For 48-bit addressing, bits 48-63 must all be copies of bit 47 (sign extension). This creates two valid address ranges: 0x0000000000000000 to 0x00007FFFFFFFFFFF (user space) and 0xFFFF800000000000 to 0xFFFFFFFFFFFFFFFF (kernel space). Addresses in the 'non-canonical hole' between these ranges cause a general protection fault if accessed.","variant":"tip"},"type":"callout"},{"data":{"rows":[["Standard (48-bit)","48","4","128 TB (0x0 - 0x7FFFFFFFFFFF)","128 TB (0xFFFF800000000000 - 0xFFFFFFFFFFFFFFFF)"],["5-Level Paging (57-bit)","57","5","64 PB","64 PB"]],"caption":"x86-64 Virtual Address Space Configuration","headers":["Configuration","Virtual Bits","Page Table Levels","User Space Size","Kernel Space Size"]},"type":"table"},{"data":{"content":"**The canonical address requirement explained:**\n\nConsider a 48-bit address like `0x00007FFF12345678`. In 64-bit form, bits 48-63 must equal bit 47. Since bit 47 is 0, the full 64-bit representation is `0x00007FFF12345678` (bits 48-63 are all 0).\n\nFor a kernel address like `0xFFFF800012345678`, bit 47 is 1, so bits 48-63 must all be 1, giving the full 64-bit form `0xFFFF800012345678`.\n\nAny address in the non-canonical hole (e.g., `0x0001000000000000`) triggers a General Protection Fault (#GP) when dereferenced. This architectural feature provides a natural security boundary between user and kernel space."},"type":"text"},{"data":{"fileName":"canonical_address_check.c","languages":[{"code":"$6d","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":1},{"id":"linux-user-space-layout","title":"The Linux User Space Layout","content":[{"data":{"content":"Within the 128 TB user space region, Linux organizes process memory into well-defined regions. Each region serves a specific purpose and has distinct properties regarding permissions, growth behavior, and lifecycle.\n\n**The classic process memory layout (low to high addresses):**\n\n1. **NULL/Guard Page** (0x0): Intentionally unmapped to catch null pointer dereferences\n2. **Text Segment** (~0x400000): Executable code, read-only and executable\n3. **Data Segment**: Initialized global/static variables, read-write\n4. **BSS Segment**: Uninitialized global/static variables, zero-filled at load\n5. **Heap**: Dynamic allocations via malloc/new, grows upward\n6. **Memory-Mapped Regions**: Shared libraries, mmap files, anonymous mappings\n7. **Stack**: Local variables and call frames, grows downward\n\nThis layout isn't arbitrary—it reflects decades of Unix design evolution and x86 architecture constraints."},"type":"text"},{"data":{"icon":"AlertCircle","title":"ASLR Changes Everything","content":"Modern Linux systems enable Address Space Layout Randomization (ASLR) by default. With ASLR, the base addresses of stack, heap, shared libraries, and even the executable itself are randomized at each execution. The conceptual layout remains the same, but absolute addresses vary. You can disable ASLR for debugging with 'echo 0 > /proc/sys/kernel/randomize_va_space' (requires root).","variant":"warning"},"type":"callout"},{"data":{"height":"600px","mermaidSyntax":"graph TD\n subgraph \"Linux x86-64 User Space Layout (128 TB)\"\n A[\"0x00007FFFFFFFFFFF\n━━━━━━━━━━━━━━━━\nTop of User Space\"]\n B[\"Stack (grows ↓)\nLocal variables, return addresses\n~8MB default limit\"]\n C[\"↓ Guard Pages ↓\"]\n D[\"mmap Region (grows ↓)\nShared libraries (.so files)\nAnonymous mappings\nMemory-mapped files\"]\n E[\"Random Gap (ASLR)\"]\n F[\"Heap (grows ↑)\nmalloc(), new, brk()\"]\n G[\"BSS Segment\nUninitialized globals (zero-filled)\"]\n H[\"Data Segment\nInitialized global/static variables\"]\n I[\"Text Segment\nExecutable code (read-only)\nStarting ~0x400000\"]\n J[\"Reserved/NULL Page\n0x0000000000000000\"]\n end\n \n A --> B\n B --> C\n C --> D\n D --> E\n E --> F\n F --> G\n G --> H\n H --> I\n I --> J"},"type":"mermaid-excalidraw"},{"data":{"content":"$6e"},"type":"text"},{"data":{"fileName":"memory_layout_demo.c","languages":[{"code":"$6f","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":2},{"id":"stack-vs-heap","title":"Stack vs Heap: Growth Dynamics and Limits","content":[{"data":{"content":"$70"},"type":"text"},{"data":{"rows":[["Growth Direction","Downward (high → low)","Upward (low → high)"],["Allocation Speed","O(1) - just move stack pointer","Variable - depends on allocator"],["Deallocation","Automatic on function return","Explicit (free/delete)"],["Default Size","~8 MB per thread","Limited by address space"],["Fragmentation","None (LIFO discipline)","Can be severe over time"],["Thread Safety","Thread-private by default","Shared, requires synchronization"],["Cache Locality","Excellent (recent data hot)","Variable (scattered allocations)"]],"caption":"Stack vs Heap Comparison","headers":["Property","Stack","Heap"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Stack-Heap Collision","content":"In older 32-bit systems, the stack growing down and heap growing up could theoretically collide. Modern 64-bit systems place huge gaps between them, and the mmap region sits in between. Guard pages prevent silent overflows. However, a thread's stack exhaustion remains a real risk—especially with deep recursion or large stack allocations (e.g., large arrays as local variables).","variant":"warning"},"type":"callout"},{"data":{"content":"**The mmap region and its role:**\n\nBetween the stack and heap lies the **mmap region**, which handles:\n\n1. **Shared Libraries**: Every `.so` file loaded into the process\n2. **Memory-Mapped Files**: Files accessed via `mmap()` system call\n3. **Anonymous Mappings**: Large allocations from malloc, thread stacks\n4. **Shared Memory**: IPC mechanisms like System V shared memory\n\nThe kernel typically places the mmap region starting just below the stack and growing downward. With 128 TB of user space, there's ample room between stack top (~0x7FFFFFFFFFFF) and heap (typically starting around 0x10000000000 or lower)."},"type":"text"},{"data":{"fileName":"stack_limits.c","languages":[{"code":"$71","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":3},{"id":"reading-proc-maps","title":"Reading /proc/[pid]/maps: The Complete Memory Map","content":[{"data":{"content":"The `/proc/[pid]/maps` file provides a complete snapshot of a process's virtual memory layout. This pseudo-file is indispensable for debugging, security analysis, and understanding how the kernel organizes process memory.\n\n**Format of each line:**\n\n```\naddress perms offset dev inode pathname\n00400000-00452000 r-xp 00000000 fd:00 12345678 /bin/cat\n```\n\n**Field breakdown:**"},"type":"text"},{"data":{"rows":[["`address`","Start-end virtual addresses (hexadecimal)"],["`perms`","Permissions: r=read, w=write, x=execute, p=private/s=shared"],["`offset`","Offset into the mapped file (for file-backed mappings)"],["`dev`","Device (major:minor) of the mapped file"],["`inode`","Inode number on that device"],["`pathname`","File path, or special indicators like [heap], [stack], [vdso]"]],"headers":["Field","Description"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"Special Pseudo-Paths","content":"The pathname field has special values: [heap] = process heap, [stack] = main thread stack, [vdso] = virtual dynamic shared object (kernel-provided fast syscalls), [vvar] = kernel-provided variables, [vsyscall] = legacy fast syscall page. Anonymous mappings have no pathname—these are often memory allocated via mmap(NULL, ...).","variant":"tip"},"type":"callout"},{"data":{"fileName":"proc_maps_example.txt","languages":[{"code":"$72","label":"Text","value":"text"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Permission patterns and their meaning:**"},"type":"text"},{"data":{"rows":[["`r-xp`","Code sections (.text)","Normal: code is executable but not writable"],["`r--p`","Read-only data (.rodata)","Constants, string literals"],["`rw-p`","Data sections (.data, .bss), heap, stack","Writable but not executable (W^X)"],["`---p`","Guard pages","Inaccessible; triggers fault if accessed"],["`r-xs`","Shared executable code","Multiple processes share same physical pages"],["`rwxp`","JIT code regions","**Security concern**: Self-modifying code"]],"headers":["Pattern","Typical Use","Security Implications"]},"type":"table"},{"data":{"content":"**The W^X (Write XOR Execute) principle:**\n\nModern systems enforce that memory is either writable OR executable, but not both simultaneously. This makes exploitation harder—attackers cannot write shellcode and execute it in the same memory region. Regions marked `rwxp` (like JIT compilers use) are exceptions that require extra care."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"aslr-modern-security","title":"ASLR and Modern Memory Layout Security","content":[{"data":{"content":"**Address Space Layout Randomization (ASLR)** fundamentally changes how we think about memory layout. Instead of predictable addresses, modern Linux randomizes the base addresses of key memory regions at each execution.\n\n**What ASLR randomizes:**\n\n1. **Stack base**: The starting address of the main thread's stack\n2. **mmap base**: Where shared libraries and anonymous mappings begin\n3. **Heap base**: The starting address of the brk heap (partial randomization)\n4. **Executable base**: If compiled as PIE (Position Independent Executable)\n5. **vDSO base**: The virtual dynamic shared object location\n\n**ASLR entropy (randomness) on x86-64 Linux:**"},"type":"text"},{"data":{"rows":[["Stack","22 bits","~4 million locations"],["mmap","28 bits","~268 million locations"],["Executable (PIE)","28 bits","~268 million locations"],["Heap","13 bits","~8,192 locations"],["vDSO","16 bits","~65,536 locations"]],"headers":["Region","Entropy Bits","Possible Locations"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"ASLR Is Not Magic","content":"ASLR makes exploitation harder, not impossible. Information leaks (reading a pointer value) can defeat ASLR. 32-bit systems have insufficient entropy—the entire address space can be brute-forced in minutes. Heap ASLR is weaker than stack/mmap ASLR. Non-PIE executables load at fixed addresses, reducing ASLR effectiveness.","variant":"warning"},"type":"callout"},{"data":{"fileName":"aslr_demonstration.sh","languages":[{"code":"$73","label":"Bash","value":"bash"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Position Independent Executables (PIE):**\n\nFor ASLR to protect the main executable, it must be compiled as a Position Independent Executable (PIE). PIE uses relative addressing instead of absolute addresses, allowing the kernel to load the executable at any address.\n\n```bash\n# Check if a binary is PIE\nfile /bin/ls\n# Output includes 'pie' if position-independent\n\n# Check with readelf\nreadelf -h /bin/ls | grep Type\n# DYN = PIE, EXEC = non-PIE\n\n# Compile as PIE (usually default)\ngcc -pie -fPIE -o program program.c\n\n# Compile as non-PIE (for debugging or special cases)\ngcc -no-pie -o program program.c\n```\n\n**Impact on memory layout:**\n\nWith PIE enabled, even the executable's code, data, and BSS segments are randomized. Without PIE, these remain at fixed addresses (typically starting at 0x400000), providing attackers a stable foothold for return-oriented programming (ROP) attacks."},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"summary-key-insights","title":"Summary: Mastering Virtual Memory Layout","content":[{"data":{"content":"We've explored the complete virtual memory layout of Linux processes on x86-64, from hardware constraints to security mechanisms. Let's consolidate the essential concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Canonical addresses divide the 48-bit space** — User space occupies 0x0 to 0x7FFFFFFFFFFF; kernel space occupies 0xFFFF800000000000 to 0xFFFFFFFFFFFFFFFF. The non-canonical gap provides hardware-enforced separation.","**Process layout follows a logical order** — From low to high: NULL guard page, text, data, BSS, heap (growing up), mmap region, and stack (growing down). Each region has specific permissions and purposes.","**Stack and heap grow toward each other** — On 64-bit systems, the vast address space prevents collisions. Stack is limited (~8MB), while heap can consume most of the address space.","**/proc/[pid]/maps reveals everything** — This file shows every memory region, its permissions, backing file, and associated pseudo-path. Essential for debugging and security analysis.","**ASLR randomizes base addresses** — Stack, mmap, heap, and PIE executables get random base addresses at each execution, complicating exploitation.","**W^X enforces write XOR execute** — Memory is either writable or executable, not both. This prevents classic shellcode injection attacks."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the complete virtual memory layout of Linux processes on x86-64. This knowledge is fundamental for systems programming, debugging, and security work. Next, we'll examine how x86-64 page tables translate these virtual addresses to physical memory—the mechanism that makes this entire abstraction possible.","variant":"success"},"type":"callout"},{"data":{"content":"**What's next:**\n\nIn the next page, we'll dive into the x86-64 page table hierarchy—the 4-level structure that translates virtual addresses to physical frames. We'll examine page table entries, their permission bits, and how the kernel manages this translation infrastructure."},"type":"text"}],"titleType":"number","titleNumber":6}],"isLocked":false},{"id":"seed_2620ec7d7cb7b1c5a5fcaa874cbf8304","title":"Page Tables (x86-64)","order":1,"content":null,"isLocked":true},{"id":"seed_53213343bcccd09d763cefd4995dcf5b","title":"Kernel Memory","order":2,"content":null,"isLocked":true},{"id":"seed_fae5b18544dadcefd5f8ba09900fdb67","title":"User Memory","order":3,"content":null,"isLocked":true},{"id":"seed_15467e7178e2879a7d437bd5ac3d9e04","title":"Memory Zones","order":4,"content":null,"isLocked":true}]}}