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: <ad27a7b8-f21d-47e5-8a3a-131cc2fb1398@p183>
Date: Thu, 20 Feb 2025 11:44:35 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
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 07:53:28AM +0100, Greg KH wrote:
> 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" :)

"struct class" is the trivialest of the problems.

> 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.

If it is not source compatible with C then it is not an option,
for the same reason Rust is not an option.