Previously:
v4.5. The v4.6 Linux kernel release included a bunch of stuff, with much more of it under the KSPP umbrella.
seccomp support for parisc
Helge Deller added
seccomp support for parisc, which including plumbing support for PTRACE_GETREGSET to get the self-tests working.
x86 32-bit mmap ASLR vs unlimited stack fixed
Hector Marco-Gisbert
removed a long-standing limitation to mmap ASLR on 32-bit x86, where setting an unlimited stack (e.g.
ulimit -s unlimited ) would turn off mmap ASLR (which provided a way to bypass ASLR when executing setuid processes). Given that ASLR entropy can now be controlled directly (see the
v4.5 post), and that the cases where this created an actual problem are very rare, means that if a system sees collisions between unlimited stack and mmap ASLR, they can just adjust the 32-bit ASLR entropy instead.
x86 execute-only memory
Dave Hansen added
Protection Key support for future x86 CPUs and, as part of this, implemented support for
execute only memory in user-space. On pkeys-supporting CPUs, using
mmap(..., PROT_EXEC) (i.e. without
PROT_READ) will mean that the memory can be executed but cannot be read (or written). This provides some mitigation against automated ROP gadget finding where an executable is read out of memory to find places that can be used to build a malicious execution path. Using this will require changing some linker behavior (to avoid putting data in executable areas), but seems to otherwise Just Work. I m looking forward to either emulated QEmu support or access to one of these fancy CPUs.
CONFIG_DEBUG_RODATA enabled by default on arm and arm64, and mandatory on x86
Ard Biesheuvel (
arm64) and I (
arm) made the poorly-named CONFIG_DEBUG_RODATA enabled by default. This feature controls whether the kernel enforces proper memory protections on its own memory regions (code memory is executable and read-only, read-only data is actually read-only and non-executable, and writable data is non-executable). This protection is a fundamental security primitive for kernel self-protection, so making it on-by-default is required to start any kind of attack surface reduction within the kernel.
On x86 CONFIG_DEBUG_RODATA was already enabled by default, but, at Ingo Molnar s suggestion, I made it
mandatory: CONFIG_DEBUG_RODATA cannot be turned off on x86. I expect we ll get there with arm and arm64 too, but the protection is still somewhat new on these architectures, so it s reasonable to continue to leave an out for developers that find themselves tripping over it.
arm64 KASLR text base offset
Ard Biesheuvel reworked a ton of arm64 infrastructure to support kernel relocation and, building on that, Kernel Address Space Layout Randomization of the
kernel text base offset (and module base offset). As with x86 text base KASLR, this is a probabilistic defense that raises the bar for kernel attacks where finding the KASLR offset must be added to the chain of exploits used for a successful attack. One big difference from x86 is that the entropy for the KASLR must come either from Device Tree (in the
/chosen/kaslr-seed property) or from UEFI (via
EFI_RNG_PROTOCOL), so if you re building arm64 devices, make sure you have a strong source of early-boot entropy that you can expose through your boot-firmware or boot-loader.
zero-poison after free
Laura Abbott reworked a bunch of the kernel memory management debugging code to add
zeroing of freed memory, similar to PaX/Grsecurity s
PAX_MEMORY_SANITIZE feature. This feature means that memory is cleared at free, wiping any sensitive data so it doesn t have an opportunity to leak in various ways (e.g. accidentally uninitialized structures or padding), and that certain types of use-after-free flaws cannot be exploited since the memory has been wiped. To take things even a step further, the poisoning can be verified at allocation time to make sure that nothing wrote to it between free and allocation (called sanity checking ), which can catch another small subset of flaws.
To understand the pieces of this, it s worth describing that the kernel s higher level allocator, the page allocator (e.g.
__get_free_pages()) is used by the finer-grained slab allocator (e.g.
kmem_cache_alloc(),
kmalloc()). Poisoning is handled separately in both allocators. The zero-poisoning happens at the page allocator level. Since the slab allocators tend to do their own allocation/freeing, their poisoning happens separately (since on slab free nothing has been freed up to the page allocator).
Only limited performance tuning has been done, so the penalty is rather high at the moment, at
about 9% when doing a kernel build workload. Future work will include some exclusion of frequently-freed caches (similar to PAX_MEMORY_SANITIZE), and making the options entirely CONFIG controlled (right now both CONFIGs are needed to build in the code, and a kernel command line is needed to activate it). Performing the sanity checking (mentioned above) adds another roughly 3% penalty. In the general case (and once the performance of the poisoning is improved), the security value of the sanity checking isn t worth the performance trade-off.
Tests for the features can be found in lkdtm as
READ_AFTER_FREE and
READ_BUDDY_AFTER_FREE. If you re feeling especially paranoid and have enabled sanity-checking,
WRITE_AFTER_FREE and
WRITE_BUDDY_AFTER_FREE can test these as well.
To perform zero-poisoning of page allocations and (currently non-zero) poisoning of slab allocations, build with:
CONFIG_DEBUG_PAGEALLOC=n
CONFIG_PAGE_POISONING=y
CONFIG_PAGE_POISONING_NO_SANITY=y
CONFIG_PAGE_POISONING_ZERO=y
CONFIG_SLUB_DEBUG=y
and enable the page allocator poisoning and slab allocator poisoning at boot with this on the kernel command line:
page_poison=on slub_debug=P
To add sanity-checking, change
PAGE_POISONING_NO_SANITY=n, and add
F to
slub_debug as
slub_debug=PF .
read-only after init
I added the
infrastructure to support making certain kernel memory read-only after kernel initialization (inspired by a small part of PaX/Grsecurity s KERNEXEC functionality). The goal is to continue to reduce the attack surface within the kernel by making even more of the memory, especially function pointer tables, read-only (which depends on
CONFIG_DEBUG_RODATA above).
Function pointer tables (and similar structures) are frequently targeted by attackers when redirecting execution. While many are already declared
const in the kernel source code, making them read-only (and therefore unavailable to attackers) for their entire lifetime, there is a class of variables that get initialized during kernel (and module) start-up (i.e. written to during functions that are marked
__init ) and then never (intentionally) written to again. Some examples are things like the VDSO, vector tables, arch-specific callbacks, etc.
As it turns out, most architectures with kernel memory protection already delay making their data read-only until after
__init (see
mark_rodata_ro()), so it s trivial to declare a new data section (
.data..ro_after_init ) and add it to the existing read-only data section (
.rodata ). Kernel structures can be annotated with the new section (via the
__ro_after_init macro), and they ll become read-only once boot has finished.
The next step for attack surface reduction infrastructure will be to create a kernel memory region that is passively read-only, but can be made temporarily writable (by a single un-preemptable CPU), for storing sensitive structures that are written to only very rarely. Once this is done, much more of the kernel s attack surface can be made read-only for the majority of its lifetime.
As people identify places where
__ro_after_init can be used, we can grow the protection. A good place to start is to look through the
PaX/Grsecurity patch to find uses of
__read_only on variables that are only written to during
__init functions. The rest are places that will need the temporarily-writable infrastructure (PaX/Grsecurity uses
pax_open_kernel()/
pax_close_kernel() for these).
That s it for v4.6, next up will be
v4.7!
2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
I attended this year's Linux Kernel Summit in Santa Fe, NM, USA and
made notes on some of the sessions that were relevant to Debian.
LWN also
reported many of the discussions.
This is the second and last part of my notes;
part 1 is here.
Kernel Hardening
Kees Cook presented the ongoing work on upstream kernel hardening,
also known as the
Kernel
Self-Protection Project or KSPP.
GCC plugins
The kernel build system can now build and use GCC plugins to
implement some protections. This requires gcc 4.5 and the plugin
headers installed. It has been tested on x86, arm, and arm64. It
is disabled by CONFIG_COMPILE_TEST because CI
systems using allmodconfig/allyesconfig probably don't have those
installed, but this ought to be changed at some point.
There was a question as to how plugin headers should be installed
for cross-compilers or custom compilers, but I didn't hear a clear
answer to this. Kees has been prodding distribution gcc maintainers
to package them. Mark Brown mentioned the Linaro toolchain being
widely used; Kees has not talked to its maintainers yet.
Probabilistic protections
These protections are based on hidden state that an attacker will
need to discover in order to make an effective attack; they
reduce the probability of success but don't prevent it
entirely.
Kernel address space layout randomisation (KASLR) has now been
implemented on x86, arm64, and mips for the kernel image.
(Debian enables this.) However there are still lots of information
leaks that defeat this. This could theoretically be improved by
relocating different sections or smaller parts of the kernel
independently, but this requires re-linking at boot. Aside from
software information leaks, the branch target predictor on (common
implementations of) x86 provides a side channel to find addresses of
branches in the kernel.
Page and heap allocation, etc., is still quite predictable.
struct randomisation (RANDSTRUCT plugin from grsecurity)
reorders members in (a) structures containing only function pointers
(b) explicitly marked structures. This makes it very hard to attack
custom kernels where the kernel image is not readable. But even for
distribution kernels, it increases the maintenance burden for
attackers.
Deterministic protections
These protections block a class of attacks completely.
Read-only protection of kernel memory is either mandatory or enabled
by default on x86, arm, and arm64. (Debian enables this.)
Protections against execution of user memory in kernel mode are now
implemented in hardware on x86 (SMEP, in Intel processors from
Skylake onward) and on arm64 (PXN, from ARMv8.1). But Skylake is
not available for servers and ARMv8.1 is not yet implemented at all!
s390 always had this protection.
It may be possible to 'emulate' this using other hardware
protections. arm (v7) and arm64 now have this, but x86 doesn't.
Linus doesn't like the overhead of previously proposed
implementations for x86. It is possible to do this using PCID (in
Intel processors from Sandy Bridge onward), which has already been
done in PaX - and this should be fast enough.
Virtually mapped stacks protect against stack overflow attacks.
They were implemented as an option for x86 only in 4.9.
(Debian enables this.)
Copies to or from user memory sometimes use a user-controlled size
that is not properly bounded. Hardened usercopy, implemented as an
option in 4.8 for many architectures, protects against this.
(Debian enables this.)
Memory wiping (zero on free) protects against some information leaks
and use-after-free bugs. It was already implemented as debug feature with
non-zero poison value, but at some performance cost. Zeroing can
be cheaper since it allows allocator to skip zeroing on
reallocation. That was implemented as an option in 4.6.
(Debian does not currently enable this but we might do if the
performance cost is low enough.)
Constification (with the CONSTIFY gcc plugin) reduces the
amount of static data that can be written to. As
with RANDSTRUCT, this is applied to function pointer tables
and explicitly marked structures. Instances of some types need to
be modified very occasionally. In PaX/Grsecurity this is done with
pax_ open,close _kernel() which
globally disable write protection temporarily. It would be preferable
to override write protection in a more directed way, so that the
permission to write doesn't leak into any other code that interrupts
this process. The feature is not in mainline yet.
Atomic wrap detction protects against reference-counting bugs which
can result in a use-after-free. Overflow and underflow are trapped
and result in an 'oops'. There is 
And here it is zoomed in to just Critical and High:
The line in the middle is the date from which I started the CVE search (2011). The vertical axis is actually linear time, but it s labeled with kernel releases (which are pretty regular). The numerical summary is:
The Washington Post published 
You can see one of my parts 
The MakerWare I run on Ubuntu works well. I wish they were correctly signing their repositories. Even if I use non-SSL to fetch their key, 
Here s today s snapshot of Debian s unstable archive for the past year (at the start of May you can see the archive unfreezing after the Wheezy release; the gaps were my analysis tool failing):
Ubuntu s lines are relatively flat because everything that can be built with hardening already is. Debian s graph is on a slow upward trend as more packages get migrated to dh to gain knowledge of the global flags.
Each line in the graphs represents the count of source packages that contain binary packages that have at least 1 hit for a given category. ELF is just that: a source package that ultimately produces at least 1 binary package with at least 1 ELF binary in it (i.e. produces a compiled output). The Read-only Relocations ( relro ) hardening feature is almost always done for an ELF, excepting uncommon situations. As a result, the count of ELF and relro are close on Ubuntu. In fact, examining relro is a good indication of whether or not a source package got built with hardening of any kind. So, in Ubuntu, 91.5% of the archive is built with hardening, with Debian at 55.2%.
The stack protector and fortify source features depend on characteristics of the source itself, and may not always be present in package s binaries even when hardening is enabled for the build (e.g. no functions got selected for stack protection, or no fortified glibc functions were used). Really these lines mostly indicate the count of packages that have a sufficiently high level of complexity that would trigger such protections.
The PIE and immediate binding ( bind_now ) features are specifically enabled by a package maintainer. PIE can have a noticeable performance impact on CPU-register-starved architectures like i386 (ia32), so it is neither patched on in Ubuntu, nor part of the default flags in Debian. (And bind_now doesn t make much sense without PIE, so they usually go together.) It s worth noting, however, that it probably should be the default on amd64 (x86_64), which has plenty of available registers.
Here is a comparison of default installed packages between the most recent stable releases of Ubuntu (
In theory, reducing the sensitivity will fix this