linux-kernel - Re: [PATCH] x86/Kconfig: make CFI_AUTO

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72kS8kfCcaqtG0KUN4Ywh6i4PHaFOg12jF+Y7CAb5SJLbA@mail.gmail.com>
Date: Thu, 10 Apr 2025 16:54:20 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Paweł Anikiel <panikiel@...gle.com>, 
	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>, 
	Nathan Chancellor <nathan@...nel.org>, x86@...nel.org, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, Matthew Maurer <mmaurer@...gle.com>, 
	Ramon de C Valle <rcvalle@...gle.com>
Subject: Re: [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST

On Thu, Apr 10, 2025 at 4:08 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> Maybe I've been living in C/C++ land for too long, but you either expose
> a full language feature and then everybody can use it, runtime,
> libraries and user code alike, or you don't.

I find it unlikely that C++ stdlibs happen to build and work properly
with compilers they are not tested for. Say, MS' STL with GCC or
libc++ with MSVC.

At the very least, you need to agree on builtins or `#ifdef` stuff
manually for magic bits, and you need to avoid to rely on any compiler
detail (or bug... :) anywhere (say, the non-conforming template
behavior from old MSVC), and so on. So you need an active effort to
make it work, I would expect.

And with new complex features like modules, I find it even more
unlikely the first implementations of a compiler's stdlib would happen
to work on the first implementation of the feature of another
compiler...

Now, it is true that Rust's `core` uses a lot of internal features,
precisely because they don't expect to be built by anything else that
the current (and current - 1) compiler, so they actually take
advantage of that.

It would perhaps be nice to split the "really requires magic" in
`core` from the rest somehow. In this case it wouldn't have helped
though, since the formatting machinery still uses builtins last time I
looked.

Relatedly, GCC Rust's goal is to build an old `core` at the moment, so
that they have a fixed set of things to solve.

Cheers,
Miguel