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: <202502191026.8B6FD47A1@keescook>
Date: Wed, 19 Feb 2025 10:52:37 -0800
From: Kees Cook <kees@...nel.org>
To: 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 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/

-- 
Kees Cook