Message-ID: <202502161538.33E0A340@keescook>
Date: Sun, 16 Feb 2025 15:42:31 -0800
From: Kees Cook <kees@...nel.org>
To: Jann Horn <jannh@...gle.com>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, jmill@....edu,
	joao@...rdrivepizza.com, linux-hardening@...r.kernel.org,
	linux-kernel@...r.kernel.org, luto@...nel.org,
	samitolvanen@...gle.com,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>
Subject: Re: [RFC] Circumventing FineIBT Via Entrypoints

On Thu, Feb 13, 2025 at 09:57:37PM +0100, Jann Horn wrote:
> On Thu, Feb 13, 2025 at 9:53 PM Kees Cook <kees@...nel.org> wrote:
> > On Thu, Feb 13, 2025 at 08:41:16PM +0000, Andrew Cooper wrote:
> > > On 13/02/2025 8:28 pm, Kees Cook wrote:
> > > > On Thu, Feb 13, 2025 at 01:31:30AM +0000, Andrew Cooper wrote:
> > > >>>> Assuming this is an issue you all feel is worth addressing, I will
> > > >>>> continue working on providing a patch. I'm concerned though that the
> > > >>>> overhead from adding a wrmsr on both syscall entry and exit to
> > > >>>> overwrite and restore the KERNEL_GS_BASE MSR may be quite high, so
> > > >>>> any feedback in regards to the approach or suggestions of alternate
> > > >>>> approaches to patching are welcome :)
> > > >>> Since the kernel, as far as I understand, uses FineIBT without
> > > >>> backwards control flow protection (in other words, I think we assume
> > > >>> that the kernel stack is trusted?),
> > > >> This is fun indeed.  Linux cannot use supervisor shadow stacks because
> > > >> the mess around NMI re-entrancy (and IST more generally) requires ROP
> > > >> gadgets in order to function safely.  Implementing this with shadow
> > > >> stacks active, while not impossible, is deemed to be prohibitively
> > > >> complicated.
> > > > And just validate my understanding here, this attack is fundamentally
> > > > about FineIBT, not regular CFI (IBT or not), as the validation of target
> > > > addresses is done at indirect call time, yes?
> > >
> > > I'm not sure I'd classify it like that.  As a pivot primitive, it works
> > > very widely.
> > >
> > > FineIBT (more specifically any hybrid CFI scheme which includes CET-IBT)
> > > relies on hardware to do the course grain violation detection, and some
> > > software hash for fine grain violation detection.
> > >
> > > In this case, the requirement for the SYSCALL entrypoint to have an
> > > ENDBR64 instruction means it passes the CET-IBT check (does not yield
> > > #CP), and then lacks the software hash check as well.
> > >
> > > i.e. this renders FineIBT (and other hybrid CFI schemes) rather moot,
> > > because one hole is all the attacker needs to win, if they can control a
> > > function pointer / return address.  At which point it's a large overhead
> > > for no security benefit over simple CET-IBT.
> >
> > Right, the "if they can control a function pointer" is the part I'm
> > focusing on. This attack depends on making an indirect call with a
> > controlled pointer. Non-FineIBT CFI will protect against that step,
> > so I think this is only an issue for IBT-only and FineIBT, but not CFI
> > nor CFI+IBT.
> 
> To me, "CFI" is really just a fairly abstract concept; are you talking
> specifically about the Clang scheme from
> <https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html>, or
> something else?

Ah, sorry, I mean KCFI (and note that FineIBT is a run-time alternatives
pass that transforms the "stock" KCFI):

https://clang.llvm.org/docs/ControlFlowIntegrity.html#fsanitize-kcfi
https://lpc.events/event/16/contributions/1315/
https://www.youtube.com/watch?v=bmv6blX_F_g

-Kees

-- 
Kees Cook

Powered by blists - more mailing lists