Re: [PATCH v1 1/1] x86/fred: Clear the WFE bit in missing-ENDBRANCH #CP
From: Xin Li
Date: Wed Sep 11 2024 - 19:44:43 EST
On 9/11/2024 4:35 PM, Andrew Cooper wrote:
On 12/09/2024 12:19 am, Xin Li (Intel) wrote:
The WFE, i.e., WAIT_FOR_ENDBRANCH, bit in the augmented CS of FRED
stack frame is set to 1 in missing-ENDBRANCH #CP exceptions.
The CPU will generate another missing-ENDBRANCH #CP if the WFE bit
is left as 1, because the indirect branch tracker will be set in
the WAIT_FOR_ENDBRANCH state upon completion of the following ERETS
instruction and the CPU will restart from the IP that just caused a
previous missing-ENDBRANCH #CP.
Clear the WFE bit to avoid dead looping in missing-ENDBRANCH #CP.
Signed-off-by: Xin Li (Intel) <xin@xxxxxxxxx>
Ah - good. Finally some evidence that this hole in CET has been plugged
by FRED.
However, I'd suggest describing it differently.
Yep, it's a much better story including historical issues with IDT.
I will use it as the comment above ibt_clear_fred_wfe() in the next
iteration, but keep the change log. Is it okay?
By definition, all missing-ENDBRANCH #CPs are a result of WFE && !ENDBR.
But, in original CET under IDT delivery, any transfer for
interrupt/exception/etc that does not change privilege will clobber the
WFE state because MSR_{U,S}_CET.WFE is intentionally set by microcode so
as to expect to find an ENDBR at the interrupt/exception/syscall entrypoint.
In practice, this means interrupts and exceptions hitting the kernel, or
user interrupts, loose the WFE state of the interrupted context. And
yes, this means that a well timed interrupt (to the precise instruction
boundary) will let an attacker sneak a bad function pointer past the
CET-IBT enforcement.
In FRED, the WFE state of the interrupted context (even if it is the
same privilege) is preserved and restored, in order to close this hole.
Therefore, the intentional #CP selfchecks need to clear WFE when they
are deemed to have succeeded, now that FRED is causing the state not to
get lost.
~Andrew