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: <CANiq72k-K3-Cbnm=0556sXAWs0kXBCB4oR67M4UtD=fq=kyp7A@mail.gmail.com>
Date: Mon, 24 Feb 2025 15:47:39 +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, Ralf Jung <post@...fj.de>
Subject: Re: C aggregate passing (Rust kernel policy)

On Mon, Feb 24, 2025 at 1:58 PM Theodore Ts'o <tytso@....edu> wrote:
>
> Hmm, I wonder if this is the reason of the persistent hostility that I
> keep hearing about in the Rust community against alternate
> implementations of the Rust compiler, such as the one being developed
> using the GCC backend.  *Since* the aliasing model hasn't been

I guess you are referring to gccrs, i.e. the new GCC frontend
developed within GCC (the other one, which is a backend,
rustc_codegen_gcc, is part of the Rust project, so no hostility there
I assume).

In any case, yes, there are some people out there that may not agree
with the benefits/costs of implementing a new frontend in, say, GCC.
But that does not imply everyone is hostile. In fact, as far as I
understand, both Rust and gccrs are working together, e.g. see this
recent blog post:

    https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust.html

> developed yet, potential alternate implementations might have
> different semantics --- for example, I suspect a GCC-based backend
> might *have* a way of opting out of aliasing, much like gcc and clang
> has today, and this might cramp rustcc's future choices if the kernel
> were to depend on it.

The aliasing model is not fully defined, but you can still develop
unsafe code being conservative, i.e. avoiding to rely on details that
are not established yet and thus could end up being allowed or not.

In addition, the models being researched, like the new Tree Borrows
one I linked above, are developed with existing code in mind, i.e.
they are trying to find a model that does not break the patterns that
people actually want to write. For instance, in the paper they show
how they tested ~670k tests across ~30k crates for conformance to the
new model.

In any case, even if, say, gccrs were to provide a mode that changes
the rules, I doubt we would want to use it, for several reasons, chief
among them because we would want to still compile with `rustc`, but
also because we will probably want the performance, because some
kernel developers may want to share code between userspace and
kernelspace (e.g. for fs tools) and because we may want to eventually
reuse some third-party code (e.g. a compression library).

Cheers,
Miguel