linux-kernel - Re: [PATCH v1 1/1] x86/fred: Clear the WFE bit in missing-ENDBRANCH #CP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <04674df0-a026-42d1-aacf-293f3018329f@citrix.com>
Date: Thu, 12 Sep 2024 00:35:25 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: "Xin Li (Intel)" <xin@...or.com>, linux-kernel@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 peterz@...radead.org
Subject: Re: [PATCH v1 1/1] x86/fred: Clear the WFE bit in missing-ENDBRANCH
 #CP

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@...or.com>

Ah - good.  Finally some evidence that this hole in CET has been plugged
by FRED.

However, I'd suggest describing it differently.

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