Message-ID: <CAFJgqgRN0zwwaNttS_9qnncTDnSA-HU5EgAXFrNHoPQ7U8fUxw@mail.gmail.com>
Date: Wed, 26 Feb 2025 07:57:29 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Ralf Jung <post@...fj.de>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Gary Guo <gary@...yguo.net>, 
	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, 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 Wed, Feb 26, 2025 at 4:34 AM Ralf Jung <post@...fj.de> wrote:
>
> Let me also reply to some statements made further up-thread by Ventura Jack (in
> <https://lore.kernel.org/rust-for-linux/CAFJgqgSqMO724SQxinNqVGCGc7=ibUvVq-f7Qk1=S3A47Mr-ZQ@mail.gmail.com/>):
>
> > - Aliasing in Rust is not opt-in or opt-out,
> >     it is always on.
> >     https://doc.rust-lang.org/nomicon/aliasing.html
>
> This is true, but only for references. There are no aliasing requirements on raw
> pointers. There *are* aliasing requirements if you mix references and raw
> pointers to the same location, so if you want to do arbitrary aliasing you have
> to make sure you use only raw pointers, no references. So unlike in C, you have
> a way to opt-out entirely within standard Rust.

Fair, though I did have this list item:

- Applies to certain pointer kinds in Rust, namely
    Rust "references".
    Rust pointer kinds:
    https://doc.rust-lang.org/reference/types/pointer.html

where I wrote that the aliasing rules apply to Rust "references".

>
> > - Rust has not defined its aliasing model.
>
> Correct. But then, neither has C. The C aliasing rules are described in English
> prose that is prone to ambiguities and misintepretation. The strict aliasing
> analysis implemented in GCC is not compatible with how most people read the
> standard (https://bugs.llvm.org/show_bug.cgi?id=21725). There is no tool to
> check whether code follows the C aliasing rules, and due to the aforementioned
> ambiguities it would be hard to write such a tool and be sure it interprets the
> standard the same way compilers do.
>
> For Rust, we at least have two candidate models that are defined in full
> mathematical rigor, and a tool that is widely used in the community, ensuring
> the models match realistic use of Rust.

But it is much more significant for Rust than for C, at least in
regards to C's "restrict", since "restrict" is rarely used in C, while
aliasing optimizations are pervasive in Rust. For C's "strict aliasing",
I think you have a good point, but "strict aliasing" is still easier to
reason about in my opinion than C's "restrict". Especially if you
never have any type casts of any kind nor union type punning.

And there have been claims in blog posts and elsewhere in the
Rust community that unsafe Rust is harder than C and C++.

>
> > - The aliasing rules in Rust are possibly as hard or
> >     harder than for C "restrict", and it is not possible to
> >     opt out of aliasing in Rust, which is cited by some
> >     as one of the reasons for unsafe Rust being
> >     harder than C.
>
> That is not quite correct; it is possible to opt-out by using raw pointers.

Again, I did have this list item:

- Applies to certain pointer kinds in Rust, namely
    Rust "references".
    Rust pointer kinds:
    https://doc.rust-lang.org/reference/types/pointer.html

where I wrote that the aliasing rules apply to Rust "references".

> >     the aliasing rules, may try to rely on MIRI. MIRI is
> >     similar to a sanitizer for C, with similar advantages and
> >     disadvantages. MIRI uses both the stacked borrow
> >     and the tree borrow experimental research models.
> >     MIRI, like sanitizers, does not catch everything, though
> >     MIRI has been used to find undefined behavior/memory
> >     safety bugs in for instance the Rust standard library.
>
> Unlike sanitizers, Miri can actually catch everything. However, since the exact
> details of what is and is not UB in Rust are still being worked out, we cannot
> yet make in good conscience a promise saying "Miri catches all UB". However, as
> the Miri README states:
> "To the best of our knowledge, all Undefined Behavior that has the potential to
> affect a program's correctness is being detected by Miri (modulo bugs), but you
> should consult the Reference for the official definition of Undefined Behavior.
> Miri will be updated with the Rust compiler to protect against UB as it is
> understood by the current compiler, but it makes no promises about future
> versions of rustc."
> See the Miri README (https://github.com/rust-lang/miri/?tab=readme-ov-file#miri)
> for further details and caveats regarding non-determinism.
>
> So, the situation for Rust here is a lot better than it is in C. Unfortunately,
> running kernel code in Miri is not currently possible; figuring out how to
> improve that could be an interesting collaboration.

I do not believe that you are correct when you write:

    "Unlike sanitizers, Miri can actually catch everything."

Critically and very importantly, unless I am mistaken about MIRI, and
similar to sanitizers, MIRI only checks with runtime tests. That means
that MIRI will not catch any undefined behavior that a test does
not encounter. If a project's test coverage is poor, MIRI will not
check a lot of the code when run with those tests. Please do
correct me if I am mistaken about this. I am guessing that you
meant this as well, but I do not get the impression that it is
clear from your post.

Further, MIRI, similar to sanitizers, runs much more slowly than
regular tests. I have heard numbers of MIRI running 50x slower
than the tests when not run with MIRI. This blog post claims
400x running time in one case.

    https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
        "The interpreter isn’t exactly fast, from what I’ve observed
        it’s more than 400x slower. Regular Rust can run the tests
        I wrote in less than a second, but Miri takes several minutes."

This does not count against MIRI, since it is similar to some
other sanitizers, as I understand it. But it does mean that MIRI
has some similar advantages and disadvantages to sanitizers.

Best, VJ.

Powered by blists - more mailing lists