Today's release of grsecurity® for Linux kernel version 4.9 makes good on our promise of publishing the implementation of the deterministic type-based return check portion of the Reuse Attack Protector (RAP®) initially described at H2HC in October 2015. This release builds upon the indirect call checking published in RAP's initial April 2016 publication in the grsecurity test patch for Linux 4.5. RAP is our patented and best-in-breed defense mechanism against code reuse attacks. It is the result of years of research and development into Control-Flow Integrity (CFI) technologies by PaX. The version of RAP present in the test patch released to the public today under the GPLv2 is now feature-complete. As a demonstration of its high security benefit to performance cost ratio, we're also providing the following benchmarks below, where RAP demonstrates a 5.4% performance hit in a "worst-case" kernel-bounded workload.

The benchmarks above were taken from a GCC 5.4.0-compiled grsecurity-enhanced kernel for Linux 4.9.8 with an Ubuntu 16.04.1 base kernel config on an Intel Core i7-6700 (Skylake) 3.4GHz CPU, hyperthreading disabled with a `du -s` benchmark locked to a single core in single user mode. A simple patch was applied to the kernel to permit usage of the Stack Smashing Protector (SSP)-All mode. SSP-All was chosen as a comparison since it was used for a long time by Chrome OS. SSP in general sees wide use throughout open-sourced software due to its inclusion in GCC and widespread kernel/libc support. The benchmark was chosen to demonstrate a worst-case performance scenario, where nearly all of the work being performed by the benchmark happens in the protected kernel. Real-life workloads would see much lower effective impacts.

RAP's deterministic type-based forward and backward-edge CFI checks eked out a performance win against SSP-All despite SSP-All providing only a small fraction of the security benefit of RAP. In the tests above, RAP protected all returns and indirect function calls in C, as well as all function calls in assembly. SSP-All only weakly protects returns in C code. SSP-All is vulnerable to arbitrary-read primitives, which allow one to determine its canary value, and cannot defend against non-linear stack corruption. Additional implementation details about RAP and competing attempts at solutions are discussed in the FAQ linked below.

The commercial version of RAP® provides even better performance, compile-time static analysis, LTO support (which in turn can realize additional performance gains), C++ support, and an additional highly-optimized probabilistic XOR protection on returns. RAP does not require currently-unavailable hardware to achieve its security goals, giving software publishers the ability to produce software which protects all its users from code reuse attacks like Return-Oriented Programming (ROP). A commercial cloud vendor, for instance, would be able to announce their high-security, ROP-proof cloud architecture by integrating RAP. RAP has proven its scalability and performance in protecting massive, complex codebases like the Chromium browser, the Linux kernel, and the Xen Project Hypervisor. We're excited to soon be providing this feature-complete version of RAP to stable patch subscribers as well.

For a technical deep-dive into RAP, please read the PaX Team's H2HC 2015 presentation. For a less-technical description everyone can understand of the history of code reuse attacks, how RAP works, and why it's a ground-breaking defense, we've prepared a FAQ. RAP is available commercially today. Reach us at contact@grsecurity.net for details.

ROP-lessly yours,

Brad Spengler & The PaX Team

Chromium is a registered trademark of Google Inc.
Xen Project is a registered trademark of The Linux Foundation.
Linux is the registered trademark of Linus Torvalds in the U.S and other countries.