Difference between revisions of "Kernel Self Protection Project"

From Linux Kernel Security Subsystem
Jump to: navigation, search
(this page is too long)
m (Details)
(9 intermediate revisions by the same user not shown)
Line 15: Line 15:
= Details =
= Details =
==== [[Recommended_Settings|Recommended Kernel Settings]] ====
Specific details on the project:
= Get Involved =
==== [[Kernel Self Protection Project/Get Involved|Get Involved]] ====
==== [[Kernel Self Protection Project/Work|Areas of Work Needed]] ====
Want to get involved? [http://www.openwall.com/lists/#subscribe Join] the [http://www.openwall.com/lists/kernel-hardening/ kernel hardening mailing list].
==== [[Kernel Self Protection Project/Recommended_Settings|Recommended Kernel Settings]] ====
==== [[Kernel Self Protection Project/Patch_Tracking|Patch Tracking]] ====
== Introduce Yourself ==
Send an email to introduce yourself! Then pick an area of work from below (or add a new one), coordinate on the mailing list, and get started. If your employer is brave enough to understand how critical this work is, they'll pay you to work on it. If not, the [http://www.linuxfoundation.org/ Linux Foundation]'s [https://www.coreinfrastructure.org/faq Core Infrastructure Initiative] is in a great position to fund specific work proposals. We need kernel developers, compiler developers, testers, backporters, a documentation writers.
== Patch Contribution Guidelines ==
When contributing patches for the Linux kernel, be sure to follow the Linux kernel [https://www.kernel.org/doc/html/latest/process/coding-style.html Coding Style Guide] and read about [https://www.kernel.org/doc/html/latest/process/submitting-patches.html Submitting Patches]. Even if you're only sending your patches to the kernel-hardening mailing list for some early review, it's best to get as much of the coding style and submission semantics correct to avoid reviewers needing to recommend changes in those areas.
As with any other Open Source project, it is particularly important that if you're working on upstreaming work from other Open Source projects, be sure your patches are giving credit to the original authors, that licenses are compatible, and that copyright notices are retained, etc.
In the case of new files, or other places where a copyright notice would be expected to be added, be sure to retain all copyright notices from the other project. This may require some examination of commit history. For example, [https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/grsecurity/Makefile#L3 Grsecurity's copyright notice from their most recent public patch] does not include PaX Team's copyright notice, which is only listed in the patch for GCC plugins. For Grsecurity copyright, when more specific details are not easy to find, the following could be used:
Copyright (C) 2001-2017 PaX Team, Bradley Spengler, Open Source Security Inc.
Additionally, Grsecurity has asked that contributors include this in commit messages for non-trivial code ported from Grsecurity:
$CODE is {verbatim,modified} from Brad Spengler/PaX Team's code in the last
public patch of grsecurity/PaX based on my understanding of the code. Changes
or omissions from the original code are mine and don't reflect the original
grsecurity/PaX code.
= Work Areas =
While there are already a number of upstream [[Feature List|kernel security features]], we are still missing many. While the following is far from a comprehensive list, it's at least a starting point we can add to:
== [[Bug Classes]] ==
* [[Bug Classes/Stack overflow|Stack overflow]]
* [[Bug Classes/Integer overflow|Integer overflow]]
* [[Bug Classes/Heap overflow|Heap overflow]]
* [[Bug Classes/Format string injection|Format string injection]]
* [[Bug Classes/Kernel pointer leak|Kernel pointer leak]]
* [[Bug Classes/Uninitialized variables|Uninitialized variables]]
* [[Bug Classes/Use after free|Use-after-free]]
== [[Exploit Methods|Exploitation Methods]] ==
* [[Exploit Methods/Kernel location|Kernel location]]
* [[Exploit Methods/Text overwrite|Text overwrite]]
* [[Exploit Methods/Function pointer overwrite|Function pointer overwrite]]
* [[Exploit Methods/Userspace execution|Userspace execution]]
* [[Exploit Methods/Userspace data usage|Userspace data usage]]
* [[Exploit Methods/Reused code chunks|Reused code chunks]]
= Specific TODO Items =
Besides the general work outlined above, there are number of specific tasks that have either been asked about frequently or are otherwise in need some time and attention:
* Split thread_info off of kernel stack (Done: x86, arm64, s390. Needed on arm, powerpc and others?)
* Move kernel stack to vmap area (Done: x86, s390. Needed on arm, arm64, powerpc and others?)
* Implement kernel relocation and KASLR for ARM
* Write a plugin to clear struct padding
* Write a plugin to do format string warnings correctly (gcc's -Wformat-security is bad about const strings)
* Make CONFIG_DEBUG_RODATA mandatory (done for arm64 and x86, other archs still need it)
* Convert remaining BPF JITs to eBPF JIT (with blinding)
* Write lib/test_bpf.c tests for eBPF constant blinding
* Further restriction of perf_event_open (e.g. perf_event_paranoid=3)
* Extend HARDENED_USERCOPY to use slab whitelisting (in progress)
* Extend HARDENED_USERCOPY to split user-facing malloc()s and in-kernel malloc()svmalloc stack guard pages (in progress)
* protect ARM vector table as fixed-location kernel target
* disable kuser helpers on arm
* rename CONFIG_DEBUG_LIST better and default=y
* add WARN path for page-spanning usercopy checks (instead of the separate CONFIG)
* create UNEXPECTED(), like BUG() but without the lock-busting, etc
* create defconfig "make" target for by-default hardened Kconfigs (using guidelines below)
* provide mechanism to check for ro_after_init memory areas, and reject structures not marked ro_after_init in vmbus_register()
* expand use of __ro_after_init, especially in arch/arm64
* Add stack-frame walking to usercopy implementations (Done: x86. In progress: arm64. Needed on arm, others?)
* restrict autoloading of kernel modules (like GRKERNSEC_MODHARDEN) (In progress: [http://www.openwall.com/lists/kernel-hardening/2017/02/02/21 Timgad LSM])
= Documentation =
= Documentation =
Line 95: Line 26:
For kernel protections already in upstream (or under active development) that have specific documentation:
For kernel protections already in upstream (or under active development) that have specific documentation:
==== [https://github.com/torvalds/linux/blob/master/Documentation/security/self-protection.txt Self-Protection Guidelines] ====
==== [https://www.kernel.org/doc/html/latest/security/self-protection.html Self-Protection Guidelines] ====
==== [[Kernel_Protections/HARDENED_ATOMIC|refcount_t]] ====
==== [[Kernel_Protections/refcount_t|refcount_t]] ====
: Kernel reference counter overflow protection
: Kernel reference counter overflow protection

Latest revision as of 21:27, 20 October 2021

Mission Statement

This project starts with the premise that kernel bugs have a very long lifetime, and that the kernel must be designed in ways to protect against these flaws. We must think of security beyond fixing bugs. As a community, we already find and fix individual bugs via static checkers (compiler flags, smatch, coccinelle, coverity) and dynamic checkers (kernel configs, trinity, KASan). Those efforts are important and on-going, but if we want to protect our billion Android phones, our cars, the International Space Station, and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel. We need the kernel to fail safely, instead of just running safely.

These kinds of protections have existed for years in the PaX and grsecurity patches, and in piles of academic papers. For various social, cultural, and technical reasons, they have not made their way into the upstream kernel, and this project seeks to change that. Our focus is on kernel self-protection, rather than kernel-supported userspace protections. The goal is to eliminate classes of bugs and eliminate methods of exploitation.


A short list of things to keep in mind when designing self-protection features:

  • Patience and an open mind will be needed. We're all trying to make Linux better, so let's stay focused on the results.
  • Upstream development is evolutionary, not revolutionary, which means it can sometimes take time for features to become fully realized.
  • Features will be more than finding bugs, and should be active at run-time to catch previously unknown flaws.
  • Features will not be developer-"opt-in". When a feature is enabled at build time, it should work for all code built into the kernel (which has the side-effect of also covering out-of-tree code, like in vendor forks).


Specific details on the project:

Get Involved

Areas of Work Needed

Recommended Kernel Settings

Patch Tracking


For kernel protections already in upstream (or under active development) that have specific documentation:

Self-Protection Guidelines


Kernel reference counter overflow protection