]> xenbits.xensource.com Git - people/andrewcoop/xen.git/commit
x86/shstk: Rework the stack layout to support shadow stacks
authorAndrew Cooper <andrew.cooper3@citrix.com>
Thu, 23 Apr 2020 19:20:59 +0000 (20:20 +0100)
committerAndrew Cooper <andrew.cooper3@citrix.com>
Fri, 29 May 2020 22:09:46 +0000 (23:09 +0100)
commit60016604739be61faf7196637739763d01a88a48
tree257d0701ae9e2b1cf2f24ffa298dae08cd0377ed
parent5ad05b9c249060fb0f8e8afb9215b08f04579f17
x86/shstk: Rework the stack layout to support shadow stacks

We have two free pages in the current stack.  A useful property of shadow
stacks and regular stacks is that they act as each others guard pages as far
as OoB writes go.  As wild OoB stack reads aren't likely, we don't lose any
meaningful protection from using read-only guard pages in general (rather than
non-present guard pages), but result is far simpler for Xen as a whole by not
having a feature/mode dependent stack configuration.

Move the regular IST stacks up by one page, to allow their shadow stack page
to be in slot 0.  The primary shadow stack uses slot 5.

As the shadow IST stacks are only 1k large, shuffle the order of IST vectors
to have #DF numerically highest, so there is no chance of a shadow stack
overflow clobbering the supervisor token.

The XPTI code already breaks the MEMORY_GUARD abstraction for stacks by
forcing it to be in effect (i.e. guard page not present).  To avoid having too
many configurations, do away with the concept entirely, and unconditionally
map the pages in their read-only form.

A later change will turn these properly into shadow stacks.  Some of the
comments written here are the intended result, and will become true in the
subsequent change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen/arch/x86/cpu/common.c
xen/arch/x86/mm.c
xen/arch/x86/smpboot.c
xen/arch/x86/traps.c
xen/include/asm-x86/config.h
xen/include/asm-x86/current.h
xen/include/asm-x86/mm.h
xen/include/asm-x86/processor.h