Does Making the Kernel Harder Make Making the Kernel Harder?
summary
Argument that kernel hardening measurably raises exploitation cost by changing real code: adoption of refcount_t prevents classic refcount bugs and touches about 180 files with ~500 instances, removing variable length arrays eliminates a common memory-layout hazard and sometimes speeds code, while harden_user_copy and added checks impose real runtime cost (one network benchmark shows a transient 2% hit that was later mitigated). Discussion covers tools like checkpatch, compiler warnings and the tradeoffs between developer ergonomics, churn and security value.
AI-written summary · about
chapters (17)
- 0:00Start
- 2:04Old as the C compiler
- 4:11Clever and precise
- 8:06String functions
- 9:15Automatic arrays
- 10:11Casts
- 12:31Convenient for mucking up
- 13:26Harder to get the wrong stack data
- 13:45Erase what's no longer needed
- 13:57A random thought
- 14:12Attackers and developers hate randomization
- 15:19Structures
- 16:47Stack pages are just pages
- 20:05Vulnerability is quantum
- 21:08Code Churn
- 21:41Runtime overhead
- 22:39Developer experience
related talks
29mThwarting Unknown Bugs: Hardening Features in the Mainline Linux Kernel
52mKernel Hardening: Ten Years Deep
42mLinux Kernel Hardening Techniques
35mUpstream Kernel Hardening: Recent Progress and Challenges
38mTaking Kernel Hardening to the Next Level
34mMaking C Less Dangerous
20mHardening Linux guest kernel for CC
06mQ&A