x86/cet: Remove writeable mapping of the BSPs shadow stack
authorAndrew Cooper <andrew.cooper3@citrix.com>
Tue, 15 Mar 2022 12:07:18 +0000 (12:07 +0000)
committerAndrew Cooper <andrew.cooper3@citrix.com>
Thu, 17 Mar 2022 20:34:06 +0000 (20:34 +0000)
commit37786b23b027ab83051175cb8ce9ac86cacfc58e
tree1d2e0aef46abcdb1cad5e9af74155e125a5c7097
parent89a24719b6591b48f9953fe1bd9db67adbf74736
x86/cet: Remove writeable mapping of the BSPs shadow stack

An unintended consequence of the BSP using cpu0_stack[] is that writeable
mappings to the BSPs shadow stacks are retained in the bss.  This renders
CET-SS almost useless, as an attacker can update both return addresses and the
ret will not fault.

We specifically don't want to shatter the superpage mapping .data and .bss, so
the only way to fix this is to not have the BSP stack in the main Xen image.

Break cpu_alloc_stack() out of cpu_smpboot_alloc(), and dynamically allocate
the BSP stack as early as reasonable in __start_xen().  As a consequence,
there is no need to delay the BSP's memguard_guard_stack() call.

Copy the top of cpu info block just before switching to use the new stack.
Fix a latent bug by setting %rsp to info->guest_cpu_user_regs rather than
->es; this would be buggy if reinit_bsp_stack() called schedule() (which
rewrites the GPR block) directly, but luckily it doesn't.

Finally, move cpu0_stack[] into .init, so it can be reclaimed after boot.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/arch/x86/include/asm/smp.h
xen/arch/x86/setup.c
xen/arch/x86/smpboot.c
xen/arch/x86/xen.lds.S