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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72nwouotAqJh_cm=9RG3Ns4wxX0LWXcVwp_bswE29kCrYA@mail.gmail.com>
Date: Fri, 21 Feb 2025 00:42:46 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: 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 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/

Things evolved after those discussions, which is why I ended up
writing the "Rust reference drivers" framework that got later used for
PHY:

    https://rust-for-linux.com/rust-reference-drivers

I hope that helps the document "to be taken seriously".

Cheers,
Miguel