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

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: <202502141345.C78A253D@keescook>
Date: Fri, 14 Feb 2025 13:54:19 -0800
From: Kees Cook <kees@...nel.org>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Jennifer Miller <jmill@....edu>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Jann Horn <jannh@...gle.com>, Nathan Chancellor <nathan@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	"Mike Rapoport (Microsoft)" <rppt@...nel.org>,
	Rik van Riel <riel@...riel.com>, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH] x86/kcfi: Require FRED for FineIBT

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