[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250410132522.GD9833@noisy.programming.kicks-ass.net>
Date: Thu, 10 Apr 2025 15:25:22 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Paweł Anikiel <panikiel@...gle.com>
Cc: Sami Tolvanen <samitolvanen@...gle.com>, Kees Cook <kees@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Miguel Ojeda <ojeda@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Alice Ryhl <aliceryhl@...gle.com>,
Nathan Chancellor <nathan@...nel.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST
On Thu, Apr 10, 2025 at 03:12:54PM +0200, Paweł Anikiel wrote:
> I'll let the rust maintainers answer this one.
>
> > >
> > > How is it still compatible with kCFI and not with FineIBT?
>
> kCFI keeps the original function's endbr64. If a callsite disables
> CFI, it simply jumps to that function (without any magic value
> checks), the endbr64 is there, so no #CP.
>
> With FineIBT, the original function's endbr64 gets replaced with a
> nop, and the callsite is supposed to be modified to jump to the CFI
> preamble. With CFI disabled, that modification doesn't happen
> (cfi_rewrite_callers() quietly ignores that callsite), so we jump to
> the nop, and we get a #CP.
Oh, you're attempting to do a no-cfi indirect branch? Yeah, you don't
get to do that.
I should get objtool to warn about those. They undermine the point of
CFI.
> > FWIW, CFI violations of any kind are a no-no. They're not accepted in C
> > and they're not accepted in Rust. This is clearly a Rust bug that needs
> > to be fixed ASAP. Disabling CFI is not an option.
>
> This is a known issue, but it doesn't seem to have high priority:
> https://github.com/rust-lang/rust/issues/115199
Now you get to fix it :) Because such code is unacceptable for the
kernel.
Just because some crazy Rust person sticks this in their runtime,
doesn't mean you get to use it in the kernel.
Powered by blists - more mailing lists