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: <20250219202751.GA42073@nvidia.com>
Date: Wed, 19 Feb 2025 16:27:51 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Kees Cook <kees@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.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>,
	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, Feb 19, 2025 at 11:17:59AM -0800, Kees Cook wrote:
> On Wed, Feb 19, 2025 at 02:08:21PM -0500, Steven Rostedt wrote:
> > On Wed, 19 Feb 2025 10:52:37 -0800
> > Kees Cook <kees@...nel.org> wrote:
> > 
> > > In other words, I don't see any reason to focus on replacing existing
> > > code -- doing so would actually carry a lot of risk. But writing *new*
> > > stuff in Rust is very effective. Old code is more stable and has fewer
> > > bugs already, and yet, we're still going to continue the work of hardening
> > > C, because we still need to shake those bugs out. But *new* code can be
> > > written in Rust, and not have any of these classes of bugs at all from
> > > day one.
> > 
> > I would say *new drivers* than say *new code*. A lot of new code is written
> > in existing infrastructure that doesn't mean it needs to be converted over
> > to rust.
> 
> Sorry, yes, I was more accurate in the first paragraph. :)

Can someone do some data mining and share how many "rust
opportunities" are there per cycle? Ie entirely new drivers introduced
(maybe bucketed per subsystem) and lines-of-code of C code in those
drivers.

My gut feeling is that the security argument is not so strong, just
based on numbers. We will still have so much code flowing in that will
not be Rust introducing more and more bugs. Even if every new driver
is Rust the reduction in bugs will be percentage small.

Further, my guess is the majority of new drivers are embedded
things. I strongly suspect entire use cases, like a hypervisor kernel,
server, etc, will see no/minimal Rust adoption or security improvement
at all as there is very little green field / driver work there that
could be in Rust.

Meaning, if you want to make the security argument strong you must
also argue for strategically rewriting existing parts of the kernel,
and significantly expanding the Rust footprint beyond just drivers. ie
more like binder is doing.

I think this is also part of the social stress here as the benefits of
Rust are not being evenly distributed across the community.

Jason