Linux Internals: How /proc/self/mem writes to unwritable memory (2021)
medbar
59 points
13 comments
March 08, 2026
Related Discussions
Found 5 related stories in 50.8ms across 3,471 title embeddings via pgvector HNSW
- io_uring, libaio performance across Linux kernels and an unexpected IOMMU trap tanelpoder · 61 pts · March 24, 2026 · 52% similar
- Linux Page Faults, MMAP, and userfaultfd for fast sandbox boot times shayonj · 14 pts · March 12, 2026 · 48% similar
- Show HN: Threadprocs – executables sharing one address space (0-copy pointers) jer-irl · 63 pts · March 23, 2026 · 46% similar
- Show HN: Sub-millisecond VM sandboxes using CoW memory forking adammiribyan · 106 pts · March 17, 2026 · 43% similar
- Why is the first C++ (m)allocation always 72 KB? joelsiks · 122 pts · March 01, 2026 · 43% similar
Discussion Highlights (4 comments)
bluepeter
The kernel owns the page tables. It can always find another way in.
hansendc
"On x86-64, there are two CPU settings which control the kernel’s ability to access memory." There are a couple more than two, even in 2021. Memory Protection Keys come to mind, as do the NPT/EPT tables when virtualization is in play. SEV and SGX also have their own ways of preventing the kernel from writing to memory. The CPU also has range registers that protect certain special physical address ranges, like the TDX module's range. You can't write there either. That's all that comes to mind at the moment. It's definitely a fun question!
haberman
TL;DR: when a user writes to /proc/self/mem, the kernel bypasses the MMU and hardware address translation, opting to emulate it in software (including emulated page faults!), which allows it to disregard any memory protection that is currently setup in the page tables.
KenoFischer
I'm still surprised I was the first one to notice when Linus tried to change this - I always thought it was a pretty well known behavior.