x86/speculation: Add prctl for Speculative Store Bypass mitigation
authorThomas Gleixner <tglx@linutronix.de>
Sun, 29 Apr 2018 13:26:40 +0000 (15:26 +0200)
committerThomas Gleixner <tglx@linutronix.de>
Thu, 3 May 2018 11:55:51 +0000 (13:55 +0200)
commita73ec77ee17ec556fe7f165d00314cb7c047b1ac
treefc626ec0298a4d788dbd8705aacfdce3e3e68bcc
parent885f82bfbc6fefb6664ea27965c3ab9ac4194b8c
x86/speculation: Add prctl for Speculative Store Bypass mitigation

Add prctl based control for Speculative Store Bypass mitigation and make it
the default mitigation for Intel and AMD.

Andi Kleen provided the following rationale (slightly redacted):

 There are multiple levels of impact of Speculative Store Bypass:

 1) JITed sandbox.
    It cannot invoke system calls, but can do PRIME+PROBE and may have call
    interfaces to other code

 2) Native code process.
    No protection inside the process at this level.

 3) Kernel.

 4) Between processes.

 The prctl tries to protect against case (1) doing attacks.

 If the untrusted code can do random system calls then control is already
 lost in a much worse way. So there needs to be system call protection in
 some way (using a JIT not allowing them or seccomp). Or rather if the
 process can subvert its environment somehow to do the prctl it can already
 execute arbitrary code, which is much worse than SSB.

 To put it differently, the point of the prctl is to not allow JITed code
 to read data it shouldn't read from its JITed sandbox. If it already has
 escaped its sandbox then it can already read everything it wants in its
 address space, and do much worse.

 The ability to control Speculative Store Bypass allows to enable the
 protection selectively without affecting overall system performance.

Based on an initial patch from Tim Chen. Completely rewritten.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Documentation/admin-guide/kernel-parameters.txt
arch/x86/include/asm/nospec-branch.h
arch/x86/kernel/cpu/bugs.c