On 29/09/2022 23:29, Rick Edgecombe wrote:
> From: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx>
>
> Utilizing CET features requires a CR4 bit to be enabled as well as bits
> to be set in CET MSRs. Setting the CR4 bit does two things:
> 1. Enables the usage of WRUSS instruction, which the kernel can use to
> write to userspace shadow stacks.
> 2. Allows those individual aspects of CET to be enabled later via the MSR.
> 3. Allows CET to be enabled in guests
Point 1, yes, but the others, not really. Guests aren't interesting
because host CR4 != guest CR4.
CET is a tangled mess of control bits. The MSRs can be configured and
context switched independently CR4.
The 4 main sub-feature enablement conditions are CR4.CET &&
MSR_{U,S}_CET.{SHSTK,ENDBR}_EN.
The WRUSS instruction is keyed on CR4.CET alone. This is because
CR4.CET is the paging control which changes the interpretation of
R/O+Dirty, and is a prerequisite for any shstk memory accesses. Most
other shstk instructions have finer grain enablement conditions.
I'd suggest simplifying the commit message massively, to say that
CR4.CET is a prerequisite for all CET operation, so extend setup_cet()
to enable it for user shadow stacks.
It hopefully goes without saying that you cannot do an equivalent piece
of code for supervisor shadow stacks. If you try, you'll discover that
everything works fine until you try returning from the function which
activated the second of CR4.CET and MSR_S_CET.SHSTK_EN, and the valid
content on the shadow stack underflows.
~Andrew
P.S. There's a fun infoleak.
Userspace can probe for kernel shstk enablement using fault analysis on
the SETSSBUSY instruction. It takes #UD for !CR4.CET ||
!MSR_S_CET.SHSTK_EN, and then #GP for CPL !=0.
