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: <CAFJgqgS-SMMEE2FktuCUimdGkPWMV3HB2Eg38SiUDQK1U8=rNg@mail.gmail.com>
Date: Wed, 26 Feb 2025 06:03:20 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: "H. Peter Anvin" <hpa@...or.com>, Alice Ryhl <aliceryhl@...gle.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, 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, 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 1:21 PM Kent Overstreet
<kent.overstreet@...ux.dev> wrote:
>
> On Tue, Feb 25, 2025 at 10:16:17AM -0800, H. Peter Anvin wrote:
> >
> > I do have to say one thing about the standards process: it forces a
> > real specification to be written, as in a proper interface contract,
> > including the corner cases (which of course may be "undefined", but
> > the idea is that even what is out of scope is clear.)
>
> Did it, though?
>
> The C standard didn't really define undefined behaviour in a
> particularly useful way, and the compiler folks have always used it as a
> shield to hide behind - "look! the standard says we can!", even though
> that standard hasn't meaninfully changed it decades. It ossified things.
>
> Whereas the Rust process seems to me to be more defined by actual
> conversations with users and a focus on practicality and steady
> improvement towards meaningful goals - i.e. concrete specifications.
> There's been a lot of work towards those.
>
> You don't need a standards body to have specifications.

Some have claimed that a full specification for aliasing missing
makes unsafe Rust harder than it otherwise would be. Though
there is work on specifications as far as I understand it.

One worry I do have, is that the aliasing rules being officially
tied to LLVM instead of having its own separate specification,
may make it harder for other compilers like gccrs to implement
the same behavior for programs as rustc.

    https://doc.rust-lang.org/stable/reference/behavior-considered-undefined.html
    http://llvm.org/docs/LangRef.html#pointer-aliasing-rules

Interestingly, some other features of Rust are defined through C++
or implemented similar to C++.

    https://doc.rust-lang.org/nomicon/atomics.html
        "Rust pretty blatantly just inherits the memory model for
        atomics from C++20. This is not due to this model being
        particularly excellent or easy to understand."

    https://rust-lang.github.io/rfcs/1236-stabilize-catch-panic.html
        "Panics in Rust are currently implemented essentially as
        a C++ exception under the hood. As a result, exception
        safety is something that needs to be handled in Rust code
        today."

Exception/unwind safety may be another subject that increases
the difficulty of writing unsafe Rust. At least the major or
aspiring Rust compilers, rustc and gccrs, are all sharing
code or infrastructure with C++ compilers, so C++ reuse in
the Rust language should not hinder making new major
compilers for Rust.

Best,  VJ.