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: <59c7a1aa-7ff8-4ed1-a83f-5db43094d3a8@ralfj.de>
Date: Fri, 28 Feb 2025 09:08:03 +0100
From: Ralf Jung <post@...fj.de>
To: Martin Uecker <uecker@...raz.at>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 "Paul E. McKenney" <paulmck@...nel.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Ventura Jack
 <venturajack85@...il.com>, Kent Overstreet <kent.overstreet@...ux.dev>,
 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, 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)

Hi,

>> The reason? The standards people wanted to describe the memory model
>> not at a "this is what the program does" level, but at the "this is
>> the type system and the syntactic rules" level. So the RCU accesses
>> had to be defined in terms of the type system, but the actual language
>> rules for the RCU accesses are about how the data is then used after
>> the load.
> 
> If your point is that this should be phrased in terms of atomic
> accesses instead of accesses to atomic objects, then I absolutely
> agree with you.  This is something I tried to get fixed, but it
> is difficult. The concurrency work mostly happens in WG21
> and not WG14.
> 
> But still, the fundamental definition of the model is in terms
> of accesses and when those become visible to other threads, and
> not in terms of syntax and types.

The underlying C++ memory model is already fully defined in terms of "this is 
what the program does", and it works in terms of atomic accesses, not atomic 
objects. The atomic objects are a thin layer that the C++ type system puts on 
top, and it can be ignored -- that's how we do it in Rust.

(From a different email)
> It sounds you want to see the semantics strengthened in case
> of a data race from there being UB to having either the old
> or new value being visible to another thread, where at some
> point this could change but needs to be consistent for a
> single access as expressed in the source code.

This would definitely impact optimizations of purely sequential code. Maybe that 
is a price worth paying, but one of the goals of the C++ model was that if you 
don't use threads, you shouldn't pay for them. Disallowing rematerialization in 
entirely sequential code (just one of the likely many consequences of making 
data races not UB) contradicts that goal. Given that even in highly concurrent 
programs, most accesses are entirely sequential, it doesn't seem unreasonable to 
say that the exceptional case needs to be marked in the program (especially if 
you have a type system which helps ensure that you don't forget to do so).

Kind regards,
Ralf