The life cycle of the mm_struct
summary
Multiple regressions where an mm_struct is observed half-initialized or lingering cause real crashes: tasks with zero VMAs, incomplete setup that drops locks before exit, and a teardown that spans a read lock plus an MMU notify flush so ordering breaks. External subsystems (zswap, oom, pte-lock contention, perf) amplify races. Past mitigations move the probe lock and fix a maple-tree loop — those patches stop specific breakages but don’t generalize. Stronger solution: enforce refcount discipline (use mm_get_not_zero and proper grab/get semantics) and define a single mm lifecycle so walkers never see partially torn-down state.
AI-written summary · about
chapters (5)
- 0:00Introduction to mm_struct
- 3:23Current problems and workarounds
- 8:19Reference counting challenges
- 12:18Race conditions in VMA handling
- 14:25Root cause and solutions
related talks
34mGetting on the Same (Virtual Memory) Page: A Roundtable on Data-only Attack Mitigations
22mHunting and Exploiting Recursive MMIO Flaws in QEMU KVM
35mKSMA: Breaking Android Kernel Isolation and Rooting with ARM MMU Features
25mKernel Self-Protection Project
46mIOMMU overhead optimizations and observability
33mExploring a New Class of Kernel Exploit Primitive
38mKernel Hardening: Protecting the Protection Mechanisms
35mZephyr OS Memory Protection