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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CANiq72kVJkR=EufaZwtjgs+_Vqet3oNNBi9U9LAu_92U6BOuoA@mail.gmail.com>
Date: Thu, 10 Apr 2025 20:01:04 +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 5:14 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> Ignoring MSVC, which is a horrible joke of a compiler (or did Sutter
> finally cluebat that team into building a sane compiler?), there are
> definitely cross compiler STL implementations around.

Definitely, there are, e.g. libc++ and libstdc++, but my point was
that it doesn't happen by accident, i.e. it requires effort (perhaps
even on both sides).

[ As for MSVC, last time I used it (2020?), it was way better compared
to the VC++6 times -- at least they started to try to be conforming,
e.g. all the work behind `/permissive-`, including the two-phase name
lookup I mentioned. They also improved a bunch of thing for C to be
able to build projects out there. ]

> Again, with the exception of MSVC, Boost builds on most C++ compilers
> and is the staging ground for many new library features.

Hmm... I am not sure what you mean -- Boost works with MSVC, and Boost
tries to use standard C++. Even if it may rely on hacks or compiler
extensions at points, Boost does not need to implement e.g. a magic
`std::launder`, and I hope they don't use builtins etc.

> And the old STL (although STL really is far more a library than runtime,
> it being fully optional) will most certainly build on a new compiler
> from the same family.

[ To clarify, by "STL" above I was referring to the Microsoft's STL
project (i.e. they call it STL, but it is the full C++ standard
library). ]

The pure "STL" stuff, i.e. containers and algorithms and such, yeah,
that may not require any magic. Some Rust `core` types and functions
can also be reimplemented in normal Rust too.

> And I know Linus hates on C++ something mighty, but in this parallel
> universe where he doesn't, I would still recommend the kernel to not use
> STL and instead build its own libraries (or borrow some nice pieces here
> and there).

Yeah, we take that approach when needed; e.g. nowadays we don't use
`alloc`, which is another part of the Rust standard library that
contains things like the equivalent to `std::vector`, and we also have
our own equivalents of `core` types sometimes, e.g. our `CStr`.

And, yeah, I agree it would be ideal to be able to reuse/customize
some parts more.

Cheers,
Miguel