Kees Cook’s 2018 Linux Security Summit update reviewed Kernel Self-Protection Project (KSPP) work associated with Linux kernels 4.14 through 4.18. Its listed highlights included memory-protection measures, hardening against exploitation, and checks intended to catch unsafe kernel behavior. They are historical examples—not a checklist of features guaranteed to be enabled on a current Linux system.
What is kernel self-protection?
The Linux kernel documentation defines kernel self-protection as “the design and implementation of systems and structures within the Linux kernel to protect against security flaws in the kernel itself.” Its scope goes beyond access control: it includes removing classes of bugs, obstructing exploitation methods, and detecting attacks.
The strategy is defense in depth. Kernel developers seek to reduce the kernel’s attack surface, limit writable memory, enforce strict memory permissions, and restrict access to kernel capabilities. For example, kernel code and read-only data should not be writable; function pointers and sensitive variables should be made read-only where possible. Loading modules can also extend the attack surface. These are engineering goals, and their implementation depends on the platform and configuration. Linux kernel self-protection documentation
What did the 2018 KSPP update cover?
The Linux Foundation’s 2018 listing describes a year-in-review of KSPP work since the previous North American Linux Security Summit and an overview of defenses in Linux 4.14 through 4.18. It identifies Kees Cook with Google for the presentation. The listing highlights the following features; it does not establish that every feature was enabled on every system or provide a complete inventory of changes. Linux Security Summit presentation listing
#1 Best Overall
- Vmapped stacks
- Structure randomization
- SLUB freelist obfuscation
set_fs()checking- Fast
refcount_tprotection - Page Table Isolation
- Usercopy whitelisting
- Variable-length array (VLA) removals
- The stackleak plugin
The feature names indicate the range of approaches: some aim to prevent or detect unsafe behavior, while others make exploitation harder. The available presentation listing does not provide comparable effectiveness measurements, performance results, or per-architecture status for each item, so those should not be inferred from the list alone.
How should you interpret these protections today?
The 4.14–4.18 version range is historical. It does not show which defenses exist in a current kernel, whether a distribution enabled them, or how they are configured. Availability can depend on kernel version, architecture, and configuration. For a particular machine, check the documentation and configuration for the exact kernel build rather than assuming a 2018 feature list applies.
Rank #2
The current kernel documentation describes self-protection as a set of goals and mechanisms, not a guarantee that every defense is present everywhere. It evaluates protections against severe local attacker capabilities and emphasizes layered risk reduction. A protection may reduce the chance of a bug or make a successful exploit more difficult without eliminating all kernel vulnerabilities.
Why are kernel hardening choices a trade-off?
The kernel documentation says successful self-protection should be effective, enabled by default, require no developer opt-in, avoid performance impact, preserve kernel debugging, and include tests. It also cautions that all these goals are rarely met at once. Linux kernel self-protection documentation
That means a hardening measure should be judged not only by what threat it addresses, but also by its compatibility, operational cost, debugging impact, and test coverage. The presentation listing does not establish those trade-offs for each named 2018 feature, so it cannot support a claim that the protections had zero cost or identical behavior across systems.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why does upstream maintenance matter?
In a 2021 Google Security Blog post, Cook connected software robustness with security and argued that insufficient upstream code review and subsystem maintenance can bottleneck kernel development. This is his perspective on the importance of sustained upstream work, not a quantified measurement of the effect. Google Security Blog, 2021
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
