From: Peter Zijlstra <peterz@infradead.org>
To: "Paweł Anikiel" <panikiel@google.com>
Cc: Sami Tolvanen <samitolvanen@google.com>,
Kees Cook <kees@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Miguel Ojeda <ojeda@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Alice Ryhl <aliceryhl@google.com>,
Nathan Chancellor <nathan@kernel.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST
Date: Thu, 10 Apr 2025 15:25:22 +0200 [thread overview]
Message-ID: <20250410132522.GD9833@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAM5zL5okN67bsTs6ZodcJd45zQ_BP+ruUwOkPMY97Snma0ugzQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2025-04-10 13:25 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 11:54 Paweł Anikiel
2025-04-10 12:36 ` Peter Zijlstra
2025-04-10 12:45 ` Peter Zijlstra
2025-04-10 13:09 ` Peter Zijlstra
2025-04-10 13:18 ` Paweł Anikiel
2025-04-10 13:20 ` Alice Ryhl
2025-04-10 13:21 ` Miguel Ojeda
2025-04-10 13:26 ` Peter Zijlstra
2025-04-10 13:27 ` Miguel Ojeda
2025-04-10 13:34 ` Peter Zijlstra
2025-04-10 13:54 ` Miguel Ojeda
2025-04-10 13:57 ` Peter Zijlstra
2025-04-10 14:05 ` Miguel Ojeda
2025-04-10 14:15 ` Peter Zijlstra
2025-04-10 15:04 ` Alice Ryhl
2025-04-10 13:59 ` Alice Ryhl
2025-04-10 14:08 ` Peter Zijlstra
2025-04-10 14:54 ` Miguel Ojeda
2025-04-10 15:14 ` Peter Zijlstra
2025-04-10 18:01 ` Miguel Ojeda
2025-04-10 15:02 ` Alice Ryhl
2025-04-15 15:15 ` Miguel Ojeda
2025-04-16 10:38 ` Alice Ryhl
2025-04-16 20:20 ` Peter Zijlstra
2025-04-16 21:51 ` Kees Cook
2025-04-17 8:18 ` Peter Zijlstra
2025-04-17 18:40 ` Miguel Ojeda
2025-04-18 9:45 ` Peter Zijlstra
2025-05-06 22:19 ` Miguel Ojeda
2025-05-09 8:46 ` Alice Ryhl
2025-05-09 9:04 ` Miguel Ojeda
2025-05-09 9:11 ` Paweł Anikiel
2025-05-09 9:39 ` Alice Ryhl
2025-05-09 16:34 ` Kees Cook
2025-05-09 19:33 ` Miguel Ojeda
2025-04-10 13:12 ` Paweł Anikiel
2025-04-10 13:25 ` Peter Zijlstra [this message]
2025-04-10 15:45 ` [PATCH] objtool: Detect __nocfi calls Peter Zijlstra
2025-04-10 19:09 ` Josh Poimboeuf
2025-04-11 6:46 ` Peter Zijlstra
2025-04-10 19:32 ` Miguel Ojeda
2025-04-10 19:43 ` Sami Tolvanen
2025-04-11 6:44 ` Peter Zijlstra
2025-04-12 12:31 ` Peter Zijlstra
2025-04-10 13:50 ` [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250410132522.GD9833@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=jpoimboe@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=ojeda@kernel.org \
--cc=panikiel@google.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome