As someone who has seen almost EVERY kernel bugfix and security issue
for the past 15+ years (well hopefully all of them end up in the stable
trees, we do miss some at times when maintainers/developers forget to
mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I
can speak on this topic.
The majority of bugs (quantity, not quality/severity) we have are due to
the stupid little corner cases in C that are totally gone in Rust.
Things like simple overwrites of memory (not that rust can catch all of
these by far), error path cleanups, forgetting to check error values,
and use-after-free mistakes. That's why I'm wanting to see Rust get
into the kernel, these types of issues just go away, allowing developers
and maintainers more time to focus on the REAL bugs that happen (i.e.
logic issues, race conditions, etc.)
I'm all for moving our C codebase toward making these types of problems
impossible to hit, the work that Kees and Gustavo and others are doing
here is wonderful and totally needed, we have 30 million lines of C code
that isn't going anywhere any year soon. That's a worthy effort and is
not going to stop and should not stop no matter what.
But for new code / drivers, writing them in rust where these types of
bugs just can't happen (or happen much much less) is a win for all of
us, why wouldn't we do this? C++ isn't going to give us any of that any
decade soon, and the C++ language committee issues seem to be pointing
out that everyone better be abandoning that language as soon as possible
if they wish to have any codebase that can be maintained for any length
of time.
Rust also gives us the ability to define our in-kernel apis in ways that
make them almost impossible to get wrong when using them. We have way
too many difficult/tricky apis that require way too much maintainer
review just to "ensure that you got this right" that is a combination of
both how our apis have evolved over the years (how many different ways
can you use a 'struct cdev' in a safe way?) and how C doesn't allow us
to express apis in a way that makes them easier/safer to use. Forcing
us maintainers of these apis to rethink them is a GOOD thing, as it is
causing us to clean them up for EVERYONE, C users included already,
making Linux better overall.
And yes, the Rust bindings look like magic to me in places, someone with
very little Rust experience, but I'm willing to learn and work with the
developers who have stepped up to help out here. To not want to learn
and change based on new evidence (see my point about reading every
kernel bug we have.)
Rust isn't a "silver bullet" that will solve all of our problems, but it
sure will help in a huge number of places, so for new stuff going
forward, why wouldn't we want that?
Linux is a tool that everyone else uses to solve their problems, and
here we have developers that are saying "hey, our problem is that we
want to write code for our hardware that just can't have all of these
types of bugs automatically".
Why would we ignore that?
Yes, I understand our overworked maintainer problem (being one of these
people myself), but here we have people actually doing the work!
Yes, mixed language codebases are rough, and hard to maintain, but we
are kernel developers dammit, we've been maintaining and strengthening
Linux for longer than anyone ever thought was going to be possible.
We've turned our development model into a well-oiled engineering marvel
creating something that no one else has ever been able to accomplish.
Adding another language really shouldn't be a problem, we've handled
much worse things in the past and we shouldn't give up now on wanting to
ensure that our project succeeds for the next 20+ years. We've got to
keep pushing forward when confronted with new good ideas, and embrace
the people offering to join us in actually doing the work to help make
sure that we all succeed together.
thanks,
greg k-h
