Message-ID: <785A9F60-F687-41DE-A116-34E37F5B407A@zytor.com>
Date: Wed, 19 Feb 2025 11:33:56 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Kees Cook <kees@...nel.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
CC: 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 February 19, 2025 10:52:37 AM PST, Kees Cook <kees@...nel.org> wrote:
>On Tue, Feb 18, 2025 at 07:46:29PM +0100, Miguel Ojeda wrote:
>> On Tue, Feb 18, 2025 at 5:08 PM Christoph Hellwig <hch@...radead.org> wrote:
>> > I'd like to understand what the goal of this Rust "experiment" is:  If
>> > we want to fix existing issues with memory safety we need to do that for
>> > existing code and find ways to retrofit it.  A lot of work went into that
>> > recently and we need much more.  But that also shows how core maintainers
>> > are put off by trivial things like checking for integer overflows or
>> > compiler enforced synchronization (as in the clang thread sanitizer).
>> 
>> As I replied to you privately in the other thread, I agree we need to
>> keep improving all the C code we have, and I support all those kinds
>> of efforts (including the overflow checks).
>> 
>> But even if we do all that, the gap with Rust would still be big.
>> 
>> And, yes, if C (or at least GCC/Clang) gives us something close to
>> Rust, great (I have supported doing something like that within the C
>> committee for as long as I started Rust for Linux).
>> 
>> But even if that happened, we would still need to rework our existing
>> code, convince everyone that all this extra stuff is worth it, have
>> them learn it, and so on. Sounds familiar... And we wouldn't get the
>> other advantages of Rust.
>
>Speaking to the "what is the goal" question, I think Greg talks about it
>a bit[1], but I see the goal as eliminating memory safety issues in new
>drivers and subsystems. The pattern we've seen in Linux (via syzkaller,
>researchers, in-the-wild exploits, etc) with security flaws is that
>the majority appear in new code. Focusing on getting new code written
>in Rust puts a stop to these kinds of flaws, and it has an exponential
>impact, as Android and Usenix have found[2] (i.e. vulnerabilities decay
>exponentially).
>
>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.
>
>The other driving force is increased speed of development, as most of
>the common bug sources just vanish, so a developer has to spend much
>less time debugging (i.e. the "90/90 rules" fades). Asahi Lina discussed
>this a bit while writing the M1 GPU driver[3], "You end up reducing the
>amount of possible bugs to worry about to a tiny number"
>
>So I think the goal is simply "better code quality", which has two primary
>outputs: exponentially fewer security flaws and faster development speed.
>
>-Kees
>
>[1] https://lore.kernel.org/all/2025021954-flaccid-pucker-f7d9@gregkh
>[2] https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
>[3] https://asahilinux.org/2022/11/tales-of-the-m1-gpu/
>

Let me clarify, because I did the bad thing of mixing not just two, but four separate topics:

a. The apparent vast gap in maturity required of Rust versus C. What is our maturity policy going to be? Otherwise we are putting a lot of burden on C maintainers which is effectively wasted of the kernel configuration pulls in even one line of Rust.

This is particularly toxic given the "no parallel code" claimed in this policy document (which really needs references if it is to be taken seriously; as written, it looks like a specific opinion.)

b. Can we use existing mature tools, such as C++, to *immediately* improve the quality (not just memory safety!) of our 37-year-old, 35-million line code base and allow for further centralized improvements without the major lag required for compiler extensions to be requested and implemented in gcc (and clang) *and* dealing with the maturity issue?

Anyone willing to take bets that the kernel will still have plenty of C code in 2050?

c. The desirability of being able to get new code written in a better way. This is most definitely something Rust can do, although the maturity issue and the syntactic gap (making it harder for reviewers used to C to review code without missing details) are genuine problems. One is technical-procedural, the other is more training-aestetics.

d. Any upcoming extensions to C or C++ that can provide increased memory safety for the existing code base, or vice that due to (a) or author/maintainer preference cannot be written in Rust.

-----

Now, moving on:

A "safe C" *would* require compiler changes, and I don't believe such a proposal has even been fielded. C++, as far as I am concerned, lets us (at least to some extent) decouple that and many other things we rely on with some *really* fuggly combinations of macros and compiler extensions.

Rust code, too, would benefit here,  because it would reduce the sematic gap *and* it would carry more information that would make the bindings both more natural and more likely to be possible to automate.

So I didn't intend to present this as much of an either/or as it came across (which was entirely my fault.) But I do think it is foolish to ignore the existing 35 million lines of code and expect them to go away. 

Powered by blists - more mailing lists