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: <CANiq72mQ7YafHd6cZWZv27c9ajkF8Kz=F2kYxeQuA2FoGhsmMA@mail.gmail.com>
Date: Fri, 21 Feb 2025 01:46:00 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Martin Uecker <uecker@...raz.at>
Cc: Greg KH <gregkh@...uxfoundation.org>, Boqun Feng <boqun.feng@...il.com>, 
	"H. Peter Anvin" <hpa@...or.com>, Christoph Hellwig <hch@...radead.org>, 
	rust-for-linux <rust-for-linux@...r.kernel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, David Airlie <airlied@...il.com>, 
	linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Thu, Feb 20, 2025 at 9:57 AM Martin Uecker <uecker@...raz.at> wrote:
>
> There is currently no kernel developer actively involved, but this would
> be very helpful.
>
> (Paul McKenney is involved in C++ regarding atomics and Miguel is
> also following what we do.)

I do not attend the meetings anymore (mainly due to changes in ISO
rules and lack of time), but I try to read the discussions and reply
from time to time.

On Thu, Feb 20, 2025 at 3:09 PM Martin Uecker <uecker@...raz.at> wrote:
>
> (BTW: Rust is also not perfectly immune to such errors:
> https://rustsec.org/advisories/RUSTSEC-2023-0080.html)

That is called a soundness issue in Rust.

Virtually every non-trivial C function would have an advisory like the
one you just linked if you apply the same policy.

On Thu, Feb 20, 2025 at 4:40 PM Martin Uecker <uecker@...raz.at> wrote:
>
> Essentially, the idea is that we can start with the existing subset
> of C that is already memory safe but very limited, and incrementally
> grow this subset.   From a user perspectice, you would do the

As I said in the C committee, we need Rust-style memory safety -- not
just the ability to "disallow UB in a region".

That is, we need the ability to write safe abstractions that wrap unsafe code.

You claimed recently that Rust is not memory safe if one uses
abstractions like that. But designing those is _precisely_ what we
need to do in the kernel and other C projects out there, and that
ability is _why_ Rust is successful.

Your proposal is useful in the same way something like Wuffs is, i.e.
where it can be applied, it is great, but it is not going to help in
many cases.

For instance, in places where we would need an `unsafe` block in Rust,
we would not be able to use the "disallow UB in a region" proposal,
even if the subset is extended, even up to the point of matching the
safe Rust subset.

This is not to say we should not do it -- Rust has
`forbid(unsafe_code)`, which is similar in spirit and nice, but it is
not what has made Rust successful.

That is why something like the "Safe C++" proposal is what C++ should
be doing, and not just "Profiles" to forbid X or Y.

If someone out there wants to help getting things into C that can be
used in the Linux kernel and other projects, please ping me.

Cheers,
Miguel