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: <nptg4kade7gjjggphsbltu6t42wpqhppvgmraezcuhqvt2plnw@pjgwgwtmwovs>
Date: Sat, 22 Feb 2025 10:21:39 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: "H. Peter Anvin" <hpa@...or.com>, Kees Cook <kees@...nel.org>, 
	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 Fri, Feb 21, 2025 at 12:42:46AM +0100, Miguel Ojeda wrote:
> On Wed, Feb 19, 2025 at 8:34 PM H. Peter Anvin <hpa@...or.com> wrote:
> >
> > 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.)
> 
> There is no "no parallel code" in the document, and I would like a
> clarification on what you mean by "toxic" here.
> 
> I tried really hard to avoid misrepresenting anything, and the
> document explicitly mentions at the top that this is our
> understanding, and that the policy could change depending on what key
> maintainers and the community discuss. (If it is put into the kernel
> tree, then that solves that.).
> 
> Anyway, I can only guess you are referring to the "Are duplicated
> C/Rust drivers allowed?" point. If so, since you want references, here
> is one:
> 
>     No, don't do that, it's horrid and we have been down that road in the
>     past and we don't want to do it again.  One driver per device please.
> 
>     https://lore.kernel.org/rust-for-linux/2023091349-hazelnut-espionage-4f2b@gregkh/

I think we need a more nuanced rule there.

When you're rolling out something new of a nontrivial size, you always
want to stage the release. You don't want everyone to start using
10k-100k lines of new code at once, you want it to first hit your power
users that can debug - and maybe the new thing isn't feature complete
yet.

If a big driver is being rewritten in Rust (e.g. if we went all the way
with the nvme driver; that was one of the first prototypes) I would want
and expect that we ship both in parallel for a few cycles and make sure
the new one is working for everyone before deleting the old one.

And tends to be what we do in practice, where appropriate. blk-mq was
incrementally rolled out. No one's even contemplating ripping out
fs/aio.c and replacing it with an io_uring wrapper.

Wholesale rewrites of entire subsystems in the kernel are rare (because
we can refactor), but with Rust we'll be seeing more and more of that -
because most of the really tricky safety sandmines do occur at FFI
boundaries.