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: <173994167131.3118120.16887445524155129088@noble.neil.brown.name>
Date: Wed, 19 Feb 2025 16:07:51 +1100
From: "NeilBrown" <neil@...wn.name>
To: "Boqun Feng" <boqun.feng@...il.com>
Cc: "H. Peter Anvin" <hpa@...or.com>,
 "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>,
 "Greg KH" <gregkh@...uxfoundation.org>, "David Airlie" <airlied@...il.com>,
 linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Wed, 19 Feb 2025, Boqun Feng wrote:
> On Tue, Feb 18, 2025 at 04:58:27PM -0800, H. Peter Anvin wrote:
> [...]
> > > > David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage.
> > > 
> > > That is great, but that does not give you memory safety and everyone
> > > would still need to learn C++.
> > 
> > The point is that C++ is a superset of C, and we would use a subset of C++
> > that is more "C+"-style. That is, most changes would occur in header files,
> > especially early on. Since the kernel uses a *lot* of inlines and macros,
> > the improvements would still affect most of the *existing* kernel code,
> > something you simply can't do with Rust.
> > 
> 
> I don't think that's the point of introducing a new language, the
> problem we are trying to resolve is when writing a driver or some kernel
> component, due to the complexity, memory safety issues (and other
> issues) are likely to happen. So using a language providing type safety
> can help that. Replacing inlines and macros with neat template tricks is
> not the point, at least from what I can tell, inlines and macros are not
> the main source of bugs (or are they any source of bugs in production?).
> Maybe you have an example?

Examples would be great, wouldn't they?
Certainly we introduce lots of bugs into the kernel, and then we fix a
few of them.  Would it be useful to describe these bugs from the
perspective of the type system with an assessment of how an improved
type system - such a rust provides - could have prevented that bug.

Anyone who fixes a bug is here-by encouraged to include a paragraph in
the commit message for the fix which describes how a stronger type
system would have caught it earlier.  We can then automatically harvest
them and perform some analysis.  Include the phrase "type system" in
your commit message to allow it to be found easily.

Thanks,
NeilBrown