linux-kernel - Re: [PATCH 1/2] cfi: add CONFIG_CFI_ICALL_NORMALIZE

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] [day] [month] [year] [list]

Message-ID: <CANiq72mJF5PYU-BCShpgH-jMVetJG2PjDypexPCKnqrxHToKJw@mail.gmail.com>
Date: Tue, 30 Jul 2024 20:01:51 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nicolas@...sle.eu>, Sami Tolvanen <samitolvanen@...gle.com>, 
	Peter Zijlstra <peterz@...radead.org>, Miguel Ojeda <ojeda@...nel.org>, Kees Cook <kees@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>, 
	Matthew Maurer <mmaurer@...gle.com>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 1/2] cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERS

On Tue, Jul 30, 2024 at 6:10 PM Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> I'm adding this flag to make the bringup process for RUST easier.
>
> I'm working on enabling RUST in a new branch. We're eventually going
> to have both RUST and CFI_ICALL_NORMALIZE_INTEGERS enabled in our
> build, but the path to getting there is complex and we would like to
> turn on CFI_ICALL_NORMALIZE_INTEGERS first, and then turn on RUST
> later. Both options are non-trivial to turn on and I want to
> disentangle them.

Would it be useful for other users/distros to do that two-stage
approach as well?

In other words, if the intended end state is that everybody should
enable this if Rust is enabled, and nobody should enable it if they
don't care about Rust, then we should add this only if you think
others will also need to do this step by step. The option or commit
message could ideally explain more about this need/use case.

Cheers,
Miguel