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: <ca0cca13-2e00-419d-88c9-06faff6aaa08@ralfj.de>
Date: Wed, 26 Feb 2025 15:07:49 +0100
From: Ralf Jung <post@...fj.de>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
 Ventura Jack <venturajack85@...il.com>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
 "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,
 rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

Hi all,

On 26.02.25 14:53, Miguel Ojeda wrote:
> On Wed, Feb 26, 2025 at 2:03 PM Ventura Jack <venturajack85@...il.com> wrote:
>>
>> 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.
> 
> I don't think they are (or rather, will be) "officially tied to LLVM".

We do link to the LLVM aliasing rules from the reference, as VJ correctly 
pointed out. This is basically a placeholder: we absolutely do *not* want Rust 
to be tied to LLVM's aliasing rules, but we also are not yet ready to commit to 
our own rules. (The ongoing work on Stacked Borrows and Tree Borrows has been 
discussed elsewhere in this thread.)

Maybe we should remove that link from the reference. It just makes us look more 
tied to LLVM than we are.

Kind regards,
Ralf