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] [day] [month] [year] [list]

Message-ID: <CAFJgqgQZoG8VrLUFtCFaMtodvFZEZV-aeFvugCnF+w7WLbS_qQ@mail.gmail.com>
Date: Tue, 25 Feb 2025 09:45:22 -0700
From: Ventura Jack <venturajack85@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: torvalds@...ux-foundation.org, airlied@...il.com, boqun.feng@...il.com, 
	david.laight.linux@...il.com, ej@...i.de, gregkh@...uxfoundation.org, 
	hch@...radead.org, ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	miguel.ojeda.sandonis@...il.com, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Tue, Feb 25, 2025 at 8:42 AM H. Peter Anvin <hpa@...or.com> wrote:
>
> On February 22, 2025 2:03:48 AM PST, Ventura Jack <venturajack85@...il.com> wrote:
> >>Gcc used to initialize it all, but as of gcc-15 it apparently says
> >>"Oh, the standard allows this crazy behavior, so we'll do it by
> >default".
> >>
> >>Yeah. People love to talk about "safe C", but compiler people have
> >>actively tried to make C unsafer for decades. The C standards
> >>committee has been complicit. I've ranted about the crazy C alias
> >>rules before.
> >
> >Unsafe Rust actually has way stricter rules for aliasing than C. For you
> >and others who don't like C's aliasing, it may be best to avoid unsafe Rust.
>
> From what I was reading in this tree, Rust doesn't actually have any rules at all?!

One way to describe it may be that Rust currently has no full
official rules for aliasing, and no full specification. There are
multiple experimental research models, including stacked
borrows and tree borrows, and work on trying to officially
figure out, model, and specify the rules. Currently, people
loosely and unofficially assume some rules, as I understand
it, often with conservative assumptions of what the rules
are or could be, as Miguel Ojeda discussed. I do not know
if there is any official partial specification of the aliasing
rules, apart from the general Rust documentation.

The unofficial aliasing rules that a Rust compiler
implementation uses, have to be followed when writing
unsafe Rust, otherwise you may get undefined behavior
and memory safety bugs. Some people have argued that
a lack of specification of the aliasing rules for Rust is one
reason why writing unsafe Rust is harder than C, among
other reasons.

A lot of Rust developers use MIRI, but MIRI cannot catch
everything. One version of MIRI explicitly mentions that it
uses stacked borrows as one rule set, and MIRI also
mentions that its stacked borrow rules are still experimental:

    "= help: this indicates a potential bug in the program: it
    performed an invalid operation, but the Stacked Borrows
    rules it violated are still experimental

    = help: see
    https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md
    for further information"

There is only one major compiler for Rust so far, rustc,
and rustc has LLVM as a primary backend. I do not know
the status of rustc's other backends. gccrs is another
compiler for Rust that is a work in progress, Philip
Herron (read also his email in the tree) and others are
working on gccrs as I understand it.

Best, VJ.