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: <6pwjvkejyw2wjxobu6ffeyolkk2fppuuvyrzqpigchqzhclnhm@v5zhfpmirk2c>
Date: Sat, 22 Feb 2025 13:54:37 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Ventura Jack <venturajack85@...il.com>
Cc: 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, miguel.ojeda.sandonis@...il.com, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Sat, Feb 22, 2025 at 08:03:29AM -0700, Ventura Jack wrote:
> On Sat, Feb 22, 2025 at 7:15 AM Gary Guo <gary@...yguo.net> wrote:
> >
> > On Sat, 22 Feb 2025 03:06:44 -0700
> > 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.
> > >
> >
> > I think the frequently criticized C aliasing rules are *type-based
> > aliasing*. Rust does not have type based aliasing restrictions.
> >
> > It does have mutability based aliasing rules, but that's easier to
> > reason about, and we have mechanisms to disable them if needed at much
> > finer granularity.
> >
> > Best,
> > Gary
> 
> Are you sure that unsafe Rust has easier to reason about aliasing
> rules? Last I checked, there are two different models related to
> aliasing, tree borrows and stacked borrows, both at an experimental
> research stage. And the rules for aliasing in unsafe Rust are not yet
> fully defined. https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
> has some commentary on the aliasing rules.
> 
> From the blog post:
> >The aliasing rules in Rust are not fully defined.
> 
> Other blog posts and videos have likewise described unsafe Rust as
> being harder than C to reason about and get correct, explicitly
> mentioning the aliasing rules of unsafe Rust as being one reason
> unsafe Rust is harder than C.

I believe (Miguel was talking about this at one of the conferences,
maybe he'll chime in) that there was work in progress to solidify the
aliasing and ownership rules at the unsafe level, but it sounded like it
may have still been an area of research.

If that work is successful it could lead to significant improvements in
code generation, since aliasing causes a lot of unnecessary spills and
reloads - VLIW could finally become practical.