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: <CANiq72mtX08qvFHDdoiSKKAB4z6QyNz=WTcXY36JZzxs-JzhWw@mail.gmail.com>
Date: Wed, 19 Feb 2025 13:37:15 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: "H. Peter Anvin" <hpa@...or.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 Wed, Feb 19, 2025 at 2:00 AM H. Peter Anvin <hpa@...or.com> wrote:
>
> So at this point Rust-only kernel code (other than experimental/staging)
> should be deferred to 2034 -- or later if the distributions not included
> in the "same" are considered important -- if Rust is being held to the
> same standard as C.

This paragraph does not really give a reason, apart from "to be like C".

Why should the kernel (and its users) wait until 2034 to take advantage of it?

And, even if there were a rule about "we need to be like C", you are
not mentioning that when Clang support was introduced, it only offered
a single release of support, and then they grew the window over time,
just like we are doing for Rust. And that was for *C*. Please let me
quote commit 3519c4d6e08e ("Documentation: add minimum clang/llvm
version"):

    Based on a vote at the LLVM BoF at Plumbers 2020, we decided to start
    small, supporting just one formal upstream release of LLVM for now.

    We can probably widen the support window of supported versions over
    time.  Also, note that LLVM's release process is different than GCC's.
    GCC tends to have 1 major release per year while releasing minor updates
    to the past 3 major versions.  LLVM tends to support one major release
    and one minor release every six months.

> Well, these cases predated 2024 and the 1.78 compiler you mentioned above.

Not sure what you mean, but I think we are agreeing, i.e. before we
established the minimum, we did not attempt to support several
versions (obviously).

> That is of course pushing the time line even further out.

If you mean that we cannot just drop C in core subsystems today, then
yes, that is correct.

But we can still add Rust code for quite a lot of useful things
meanwhile, such as Android and Asahi, which already work today.

The constraint is really "drop C code" here, not "adding Rust code" --
you could, in theory, keep C code around and duplicate it in Rust. The
kernel doesn't generally do that, though.

> You can't convert the *entire existing kernel code base* with a single
> patch set, most of which can be mechanically or semi-mechanically
> generated (think Coccinelle) while retaining the legibility and
> maintainability of the code (which is often the hard part of automatic
> code conversion.)

Compiling as C++ is fine, but to get to the real benefits of using
C++, you would still have to rework and redesign code.

And, even then, you would not be able to express what Rust allows and
thus you would not get memory safety.

In summary: in a different timeline, where Rust did not exist and
"Safe C++" were implemented by GCC and Clang, I could agree with you.

If you mean doing that on top of doing Rust, then that is yet another
discussion, but: you would need people to learn C++ and Rust, and it
would complicate interop with Rust substantially.

Cheers,
Miguel