Re: Rust kernel policy

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 19 Feb 2025 16:27:51 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:

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

Drivers is the biggest part of the Linux kernel and has the biggest churn.
A lot of them are "drive by" submissions too (Let's add a driver for our
new device and work on something else). These are written by people that
are not kernel maintainers but just people trying to get their devices
working on Linux. That means they are the ones to introduce the most bugs
that Rust would likely prevent.

I was going through my own bugs to see how much Rust would help, and the
percentage was rather small. I did have a few ref counter bugs. Not the
kind for freeing, but for which left things in a state that the system
couldn't be modified (the ref count was to lock access). I'm not sure Rust
would have solved that.

So most of the bugs were accounting issues. I found a couple that were
memory safety bugs but those are not as common. I guess that's because I do
test with kmemleak which will usually detect that.

Perhaps I wouldn't need to do all the memory tests if I wrote the code in
Rust? But that's not what you are asking. As a maintainer of core code, I
run a lot of tests before sending to Linus. Which I would hope keeps the
number of bugs I introduce to a minimum. But I can't say the same for the
driver code. That's a much different beast, as to test that code, you also
need the hardware that the driver is for.

I do feel that new drivers written in Rust would help with the
vulnerabilities that new drivers usually add to the kernel.

-- Steve