KAISER: unmap most of the kernel from userspace page tables

From:		Dave Hansen <dave.hansen-AT-linux.intel.com>
To:		linux-kernel-AT-vger.kernel.org
Subject:		[PATCH 00/23] KAISER: unmap most of the kernel from userspace page tables
Date:		Tue, 31 Oct 2017 15:31:46 -0700
Message-ID:		<[email protected]>
Cc:		linux-mm-AT-kvack.org, dave.hansen-AT-linux.intel.com

tl;dr:

KAISER makes it harder to defeat KASLR, but makes syscalls and
interrupts slower. These patches are based on work from a team at
Graz University of Technology posted here[1]. The major addition is
support for Intel PCIDs which builds on top of Andy Lutomorski's PCID
work merged for 4.14. PCIDs make KAISER's overhead very reasonable
for a wide variety of use cases.

Full Description:

KAISER is a countermeasure against attacks on kernel address
information. There are at least three existing, published,
approaches using the shared user/kernel mapping and hardware features
to defeat KASLR. One approach referenced in the paper locates the
kernel by observing differences in page fault timing between
present-but-inaccessable kernel pages and non-present pages.

KAISER addresses this by unmapping (most of) the kernel when
userspace runs. It leaves the existing page tables largely alone and
refers to them as "kernel page tables". For running userspace, a new
"shadow" copy of the page tables is allocated for each process. The
shadow page tables map all the same user memory as the "kernel" copy,
but only maps a minimal set of kernel memory.

When we enter the kernel via syscalls, interrupts or exceptions,
page tables are switched to the full "kernel" copy. When the system
switches back to user mode, the "shadow" copy is used. Process
Context IDentifiers (PCIDs) are used to to ensure that the TLB is not
flushed when switching between page tables, which makes syscalls
roughly 2x faster than without it. PCIDs are usable on Haswell and
newer CPUs (the ones with "v4", or called fourth-generation Core).

The minimal kernel page tables try to map only what is needed to
enter/exit the kernel such as the entry/exit functions, interrupt
descriptors (IDT) and the kernel stacks. This minimal set of data
can still reveal the kernel's ASLR base address. But, this minimal
kernel data is all trusted, which makes it harder to exploit than
data in the kernel direct map which contains loads of user-controlled
data.

KAISER will affect performance for anything that does system calls or
interrupts: everything. Just the new instructions (CR3 manipulation)
add a few hundred cycles to a syscall or interrupt. Most workloads
that we have run show single-digit regressions. 5% is a good round
number for what is typical. The worst we have seen is a roughly 30%
regression on a loopback networking test that did a ton of syscalls
and context switches. More details about possible performance
impacts are in the new Documentation/ file.

This code is based on a version I downloaded from
(https://github.com/IAIK/KAISER). It has been heavily modified.

The approach is described in detail in a paper[2]. However, there is
some incorrect and information in the paper, both on how Linux and
the hardware works. For instance, I do not share the opinion that
KAISER has "runtime overhead of only 0.28%". Please rely on this
patch series as the canonical source of information about this
submission.

Here is one example of how the kernel image grow with CONFIG_KAISER
on and off. Most of the size increase is presumably from additional
alignment requirements for mapping entry/exit code and structures.

text data bss dec filename
11786064 7356724 2928640 22071428 vmlinux-nokaiser
11798203 7371704 2928640 22098547 vmlinux-kaiser
+12139 +14980 0 +27119

To give folks an idea what the performance impact is like, I took
the following test and ran it single-threaded:

https://github.com/antonblanchard/will-it-scale/blob/mast...

It's a pretty quick syscall so this shows how much KAISER slows
down syscalls (and how much PCIDs help). The units here are
lseeks/second:

no kaiser: 5.2M
kaiser+ pcid: 3.0M
kaiser+nopcid: 2.2M

"nopcid" is literally with the "nopcid" command-line option which
turns PCIDs off entirely.

Thanks to:
The original KAISER team at Graz University of Technology.
Andy Lutomirski for all the help with the entry code.
Kirill Shutemov for a helpful review of the code.

1. https://github.com/IAIK/KAISER
2. https://gruss.cc/files/kaiser.pdf

The code is available here:

https://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86...