linux-kernel - Re: Rust kernel policy

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: <2025022007-angelfish-smite-a69d@gregkh>
Date: Thu, 20 Feb 2025 07:53:28 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: "H. Peter Anvin" <hpa@...or.com>, Kees Cook <kees@...nel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	rust-for-linux <rust-for-linux@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
	ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Thu, Feb 20, 2025 at 09:32:15AM +0300, Alexey Dobriyan wrote:
> On Wed, Feb 19, 2025 at 11:33:56AM -0800, H. Peter Anvin wrote:
> > b. Can we use existing mature tools, such as C++, to *immediately* improve the quality (not just memory safety!) of our 37-year-old, 35-million line code base and allow for further centralized improvements without the major lag required for compiler extensions to be requested and implemented in gcc (and clang) *and* dealing with the maturity issue?
> 
> We can't and for technical reasons:
> 
> * g++ requires C99 initializers to be in declaration order,
>   even in cases where there is no reason to do so.
> 
> * g++ doesn't support __seg_gs at all:
> 
> 	$ echo -n -e 'int __seg_gs gs;' | g++ -xc++ - -S -o /dev/null
> 	<stdin>:1:14: error: expected initializer before ‘gs’
> 
>   x86 added this to improve codegen quality so this would be step backwards.
> 

And then there's my special addition to the kernel "struct class" :)

Anyway, no sane project should switch to C++ now, ESPECIALLY as many are
starting to move away from it due to the known issues with complexity
and safety in it's use.  Again, see all of the recent issues around the
C++ standard committee recently AND the proposal from Google about
Carbon, a way to evolve a C++ codebase into something else that is
maintainable and better overall.  I recommend reading at least the
introduction here:
	https://docs.carbon-lang.dev/
for details, and there are many other summaries like this one that go
into more:
	https://herecomesthemoon.net/2025/02/carbon-is-not-a-language/

In short, switching to C++ at this stage would be ignoring the lessons
that many others have already learned already, and are working to
resolve.  It would be a step backwards.

thanks,

greg k-h