linux-kernel - Re: C aggregate passing (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: <CANiq72kMQW6a991e9TgR39pmG5hVd-NcoeJANum4ap-6n=Mhhw@mail.gmail.com>
Date: Mon, 24 Feb 2025 16:43:46 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Ventura Jack <venturajack85@...il.com>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Kent Overstreet <kent.overstreet@...ux.dev>, Gary Guo <gary@...yguo.net>, airlied@...il.com, 
	boqun.feng@...il.com, david.laight.linux@...il.com, ej@...i.de, 
	gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com, 
	ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Mon, Feb 24, 2025 at 1:58 PM Theodore Ts'o <tytso@....edu> wrote:
>
> That being said, until Rust supports all of the platforms that the
> Linux kernel does has, it means that certain key abstractions can not
> be implemented in Rust --- unless we start using a GCC backend for
> Rust, or if we were to eject certain platforms from our supported
> list, such as m68k or PA-RISC....

By the way, the real constraint here is dropping C code that cannot be
replaced for all existing use cases. That, indeed, cannot happen.

But the "abstractions" (i.e. the Rust code that wraps C) themselves
can be implemented just fine, even if are only called by users under a
few architectures. That is what we are doing, after all.

Similarly, if the kernel were to allow alternative/parallel/duplicate
implementations of a core subsystem, then that would be technically
doable, since the key is not dropping the C code that users use today.
To be clear, I am not saying we do that, just trying to clarify that
the technical constraint is generally dropping C code that cannot be
replaced properly.

We also got the question about future subsystems a few times -- could
they be implemented in Rust without wrapping C? That would simplify
greatly some matters and reduce the amount of unsafe code. However, if
the code is supposed to be used by everybody, then that would make
some architectures second-class citizens, even if they do not have
users depending on that feature today, and thus it may be better to
wait until GCC gets to the right point before attempting something
like that.

That is my understanding, at least -- I hope that clarifies.

Cheers,
Miguel