Difference between revisions of "Kernel Self Protection Project"

From Linux Kernel Security Subsystem
Jump to navigation Jump to search
Line 43: Line 43:
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:
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
* Split thread_info off of kernel stack (under development on x86 already)
* Move kernel stack to vmap area
* Move kernel stack to vmap area (under development on x86 already)
* Implement kernel relocation and KASLR for ARM
* Implement kernel relocation and KASLR for ARM
* Implement PAN emulation on arm64 for ARMv8.0 hardware (pre-8.0 emulates using Domains, 8.1 and later use hardware PAN)
* Implement PAN emulation on arm64 for ARMv8.0 hardware (pre-8.0 emulates using Domains, 8.1 and later use hardware PAN)
Line 54: Line 54:
* Write lib/test_bpf.c tests for eBPF constant blinding
* Write lib/test_bpf.c tests for eBPF constant blinding
* Further restriction of perf_event_open (perf_event_paranoid=3)
* Further restriction of perf_event_open (perf_event_paranoid=3)
* arm64: fix _etext to be the bottom of kernel instead of including rodata

Revision as of 17:34, 6 July 2016

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 PaX, grsecurity, and 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.

Principles

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.
  • Features will be more than finding bugs. 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).

Get Involved

Want to get involved? Join the kernel hardening mailing list and 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 Linux Foundation's Core Infrastructure Initiative is in a great position to fund specific work proposals. We need kernel developers, compiler developers, testers, backporters, a documentation writers.

Work Areas

While there are already a number of upstream 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

Exploitation Methods

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 (under development on x86 already)
  • Move kernel stack to vmap area (under development on x86 already)
  • Implement kernel relocation and KASLR for ARM
  • Implement PAN emulation on arm64 for ARMv8.0 hardware (pre-8.0 emulates using Domains, 8.1 and later use hardware PAN)
  • 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)
  • Reorganize and rename CONFIG_DEBUG_RODATA (and related options) to something without "DEBUG" in the name
  • arm64: Make CONFIG_DEBUG_RODATA mandatory
  • 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 (perf_event_paranoid=3)