Lion Cipher Lab
See virtual memory, page faults, and copy-on-write with your own eyes
- Foundations
- Advanced
- ~90 min
- Free · no account required
Why it matters
Every program you will ever run, defend, or reverse lives inside an illusion the kernel maintains: a private virtual address space that only becomes real RAM one page at a time, on demand. Most people treat that illusion as a black box -- 'the program uses 2 GB of memory' -- and are wrong in ways that matter. They panic at a process with a 20 GB VSZ that is using 200 MB of actual RAM. They cannot explain why fork() of a 4 GB process is instant and nearly free. They read 'malloc succeeded' and assume the memory exists, then get OOM-killed the moment they write to it. They see a SIGSEGV and…
What you'll learn
- reading your own address space in /proc/self/maps: separating the executable text segment, .data, the heap, the down-growing stack, mmap'd regions, the vdso and vvar
- telling VSZ (virtual size -- address space reserved) apart from RSS (resident set size -- physical RAM actually backing it), and why only RSS is real
- proving demand paging: mmap 512 MiB you never touch, watch VSZ jump while RSS stays flat, then touch one byte per page and watch RSS climb as the kernel allocates pages on first access
- counting minor vs major page faults with getrusage(ru_minflt/ru_majflt) and /usr/bin/time -v, and knowing fresh anonymous pages are always MINOR faults (no I/O)
- proving copy-on-write across fork(): parent and child SHARE physical pages (Shared_Dirty in smaps_rollup) until the child WRITES, which triggers a COW fault and a private copy (Private_Dirty)
- enforcing memory protection: mprotect a page read-only, store into it, and catch the SIGSEGV with an SA_SIGINFO handler that reads si_addr -- how guard pages and W^X are enforced by hardware + kernel
- naming the failure modes: VSZ is a reservation you cannot capacity-plan on; memory overcommit lets allocation succeed beyond physical RAM; the OOM killer is the reckoning at first write
- the security lens: guard pages, NX/W^X, and ASLR randomizing the mmap/stack/heap base -- the kernel-side view of the machine the binexp, ASLR, and memory-allocator labs operate on
Steps in this lab
- The one idea: your memory is a promise, and only RSS is the part that came true
- Get a shell, then read your own address space in /proc/self/maps
- Demand paging: reserve 512 MiB, touch nothing, watch RSS refuse to move
- Minor vs major page faults -- and why fresh anonymous pages are always minor
- Copy-on-write across fork(): parent and child share pages until someone writes
- Enforce protection: mprotect a page read-only, write to it, catch the SIGSEGV
- The named failure modes: VSZ is a lie, overcommit is a bet, the OOM killer is the reckoning
- The judgment: the security lens, and why you now read this machine like the exploit labs do