Commit 978e1342 authored May 28, 2020 by Tony Luck Committed by Thomas Gleixner Jun 18, 2020

x86/speculation/swapgs: Check FSGSBASE in enabling SWAPGS mitigation



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 <tony.luck@intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200528201402.1708239-9-sashal@kernel.org

parent 005f141e

arch/x86/kernel/cpu/bugs.c

+2 −4

Original line number	Diff line number	Diff line
		@@ -543,14 +543,12 @@ static void __init spectre_v1_select_mitigation(void)
		* If FSGSBASE is enabled, the user can put a kernel address in
		* GS, in which case SMAP provides no protection.
		*
		* [ NOTE: Don't check for X86_FEATURE_FSGSBASE until the
		* FSGSBASE enablement patches have been merged. ]
		*
		* If FSGSBASE is disabled, the user can only put a user space
		* address in GS. That makes an attack harder, but still
		* possible if there's no SMAP protection.
		*/
		if (!smap_works_speculatively()) {
		if (boot_cpu_has(X86_FEATURE_FSGSBASE) \|\|
		!smap_works_speculatively()) {
		/*
		* Mitigation can be provided from SWAPGS itself or
		* PTI as the CR3 write in the Meltdown mitigation

Admin message