Explain how the GS/FS based addressing can be utilized in user space
applications along with the differences between the generic prctl() based
GS/FS base control and the FSGSBASE version available on newer CPUs.
Originally-by: Andi Kleen <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Signed-off-by: Chang S. Bae <email address hidden>
Reviewed-by: Tony Luck <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Andy Lutomirski <email address hidden>
Cc: H. Peter Anvin <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Tony Luck <email address hidden>
Cc: Andi Kleen <email address hidden>
Cc: Randy Dunlap <email address hidden>
Cc: Jonathan Corbet <email address hidden>
Reviewed-by: Randy Dunlap <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
The kernel needs to explicitly enable FSGSBASE. So, the application needs
to know if it can safely use these instructions. Just looking at the CPUID
bit is not enough because it may be running in a kernel that does not
enable the instructions.
One way for the application would be to just try and catch the SIGILL.
But that is difficult to do in libraries which may not want to overwrite
the signal handlers of the main application.
Enumerate the enabled FSGSBASE capability in bit 1 of AT_HWCAP2 in the ELF
aux vector. AT_HWCAP2 is already used by PPC for similar purposes.
The application can access it open coded or by using the getauxval()
function in newer versions of glibc.
Signed-off-by: Andi Kleen <email address hidden>
Signed-off-by: Chang S. Bae <email address hidden>
Reviewed-by: Tony Luck <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Andy Lutomirski <email address hidden>
Cc: H. Peter Anvin <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Tony Luck <email address hidden>
Cc: Andi Kleen <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
ee4bf42...
by
Andy Lutomirski <email address hidden>
UBUNTU: SAUCE: x86/fsgsbase/64: Enable FSGSBASE on 64bit by default and add a chicken bit
Before enabling FSGSBASE the kernel could safely assume that the content
of GS base was a user address. Thus any speculative access as the result
of a mispredicted branch controlling the execution of SWAPGS would be to
a user address. So systems with speculation-proof SMAP did not need to
add additional LFENCE instructions to mitigate.
With FSGSBASE enabled a hostile user can set GS base to a kernel address.
So they can make the kernel speculatively access data they wish to leak
via a side channel. This means that SMAP provides no protection.
Add FSGSBASE as an additional condition to enable the fence-based SWAPGS
mitigation.
Signed-off-by: Tony Luck <email address hidden>
Signed-off-by: Chang S. Bae <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Andy Lutomirski <email address hidden>
Cc: H. Peter Anvin <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Tony Luck <email address hidden>
Cc: Andi Kleen <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
75f091d...
by
"Chang S. Bae" <email address hidden>
UBUNTU: SAUCE: x86/fsgsbase/64: Use FSGSBASE instructions on thread copy and ptrace
When FSGSBASE is enabled, copying threads and reading FS/GS base using
ptrace must read the actual values.
When copying a thread, use fsgs_save() and copy the saved values. For
ptrace, the bases must be read from memory regardless of the selector
if FSGSBASE is enabled.
Suggested-by: Andy Lutomirski <email address hidden>
Signed-off-by: Chang S. Bae <email address hidden>
Reviewed-by: Tony Luck <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Andy Lutomirski <email address hidden>
Cc: H. Peter Anvin <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Tony Luck <email address hidden>
Cc: Andi Kleen <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
0d200cd...
by
Andy Lutomirski <email address hidden>
UBUNTU: SAUCE: x86/fsgsbase/64: Use FSGSBASE in switch_to() if available
With the new FSGSBASE instructions, FS/GS base can be efficiently read
and written in __switch_to(). Use that capability to preserve the full
state.
This will enable user code to do whatever it wants with the new
instructions without any kernel-induced gotchas. (There can still be
architectural gotchas: movl %gs,%eax; movl %eax,%gs may change GS base
if WRGSBASE was used, but users are expected to read the CPU manual
before doing things like that.)
This is a considerable speedup. It seems to save about 100 cycles per
context switch compared to the baseline 4.6-rc1 behavior on a Skylake
laptop.
[ chang: 5~10% performance improvements were seen by a context switch
benchmark that ran threads with different FS/GS base values (to the
baseline 4.16). ]
Signed-off-by: Andy Lutomirski <email address hidden>
Signed-off-by: Chang S. Bae <email address hidden>
Reviewed-by: Tony Luck <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Andy Lutomirski <email address hidden>
Cc: H. Peter Anvin <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Tony Luck <email address hidden>
Cc: Andi Kleen <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
bdd2a8a...
by
"Chang S. Bae" <email address hidden>
UBUNTU: SAUCE: x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions
Add CPU feature conditional FS/GS base access to the relevant helper
functions. That allows accelerating certain FS/GS base operations in
subsequent changes.
Note, that while possible, the user space entry/exit GS base operations are
not going to use the new FSGSBASE instructions. The reason is that it would
require additional storage for the user space value which adds more
complexity to the low level code and experiments have shown marginal
benefit. This may be revisited later but for now the SWAPGS based handling
in the entry code is preserved except for the paranoid entry/exit code.
Suggested-by: Tony Luck <email address hidden>
Signed-off-by: Chang S. Bae <email address hidden>
Reviewed-by: Tony Luck <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Andy Lutomirski <email address hidden>
Cc: H. Peter Anvin <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Tony Luck <email address hidden>
Cc: Andi Kleen <email address hidden>
Cc: Andrew Cooper <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
On FSGSBASE systems, the way to handle GS base in the paranoid path is
different from the existing SWAPGS-based entry/exit path handling. Document
the reason and what has to be done for FSGSBASE enabled systems.
Signed-off-by: Chang S. Bae <email address hidden>
Reviewed-by: Tony Luck <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Andy Lutomirski <email address hidden>
Cc: H. Peter Anvin <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Tony Luck <email address hidden>
Cc: Andi Kleen <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
