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: <Z7VKW3eul-kGaIT2@Mac.home>
Date: Tue, 18 Feb 2025 19:04:59 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: 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 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?

Regards,
Boqun

[...]