An obscure quirk of the /proc/*/mem pseudofile is its “punch through” semantics. Writes performed through this file will succeed even if the destination virtual memory is marked unwritable. In fact, this behavior is intentional and actively used by projects such as the Julia JIT compiler and rr debugger.
This behavior raises some questions: Is privileged code subject to virtual memory permissions? In general, to what degree can the hardware inhibit kernel memory access?
By exploring these questions, this article will shed light on the constraints the CPU can impose on the kernel, and how the kernel can bypass these constraints. To begin, we must understand how the hardware enforces memory permissions.
This post details my adventures with the Linux virtual memory subsystem, and my discovery of a creative way to taunt the OOM (out of memory) killer by accumulating memory in the kernel, rather than in userspace.
Keep reading and you’ll learn:
- Internal details of the Linux kernel’s demand paging implementation
- How to exploit virtual memory to implement highly efficient sparse data structures
- What page tables are and how to calculate the memory overhead incurred by them
- A cute way to get killed by the OOM killer while appearing to consume very little memory (great for parties)
Congratulations! You just finished developing your first contribution to the Linux kernel, and are excited to submit it. The process for doing so is tricky, with many conventions that the community has developed over time, so here is what I learned after doing so for the first time. This is intended to be a succinct supplement to the official contribution documentation.
Here is everything you need to know to set up a minimal Linux kernel dev environment on Ubuntu 20.04. It works great on small VPS instances, is optimized for a fast development cycle, and allows you to run custom binaries to exercise the specific kernel functionality being developed.