Re: [PATCH] x86/kcfi: Require FRED for FineIBT

[Kees Cook <kees@kernel.org>]

On Fri, Feb 14, 2025 at 07:39:20PM +0000, Andrew Cooper wrote:
> On 14/02/2025 7:22 pm, Kees Cook wrote:
> > diff --git a/arch/x86/include/asm/cfi.h b/arch/x86/include/asm/cfi.h
> > index ef5e0a698253..dfa2ba4cceca 100644
> > --- a/arch/x86/include/asm/cfi.h
> > +++ b/arch/x86/include/asm/cfi.h
> > @@ -93,7 +93,7 @@
> >   *
> >   */
> >  enum cfi_mode {
> > -	CFI_AUTO,	/* FineIBT if hardware has IBT, otherwise kCFI */
> > +	CFI_AUTO,	/* FineIBT if hardware has IBT, FRED, and XOM */
> 
> You discuss XOM in the commit message, but there's no check ...
> 
> >  	CFI_OFF,	/* Taditional / IBT depending on .config */
> >  	CFI_KCFI,	/* Optionally CALL_PADDING, IBT, RETPOLINE */
> >  	CFI_FINEIBT,	/* see arch/x86/kernel/alternative.c */
> > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> > index 97422292b609..acc12a6efc18 100644
> > --- a/arch/x86/kernel/alternative.c
> > +++ b/arch/x86/kernel/alternative.c
> > @@ -1323,7 +1323,9 @@ static void __apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
> >  
> >  	if (cfi_mode == CFI_AUTO) {
> >  		cfi_mode = CFI_KCFI;
> > -		if (HAS_KERNEL_IBT && cpu_feature_enabled(X86_FEATURE_IBT))
> > +		/* FineIBT requires IBT and will only be safe with FRED */
> > +		if (HAS_KERNEL_IBT && cpu_feature_enabled(X86_FEATURE_IBT) &&
> > +		    cpu_feature_enabled(X86_FEATURE_FRED))
> 
> ... here.
> 
> Is this meant to be "/* TODO: wire up XOM */" or is that accounted for
> somewhere else?

Yeah, I wasn't sure how to best capture that in here. XOM doesn't exist
yet for x86... I could add a TODO like that?

> Also, while I hate to come back and contradict myself from earlier...
> 
> Architecturally, FineIBT without FRED seems to be no improvement over
> simple IBT.  (I'd love to find some way of hardening the entrypoints,
> but I can't see a robust way of doing so.)

If you're just looking at IBT, yes. But kCFI (with or without IBT,
but without FineIBT) will do hash checking at the call site, which
should make it impossible to reach the entrypoints from an indirect call
in the first place, as they have no hash preceding them.

> However, micro-architecturally, FineIBT is still far better than simple
> IBT for speculation issue, seeing as Intel keep on staunchly refusing to
> turn off the indirect predictors by default like AMD do.
> 
> A security conscious user ought to be using FineIBT for this, given a
> choice, even if it's not perfect in other regards.

A security conscious user should use kCFI without FineIBT. :) But I
think we might be thinking about different elements of security. I am
focusing on control flow, and I think you're considering speculation?

-Kees

-- 
Kees Cook