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: <09e282a9c02fb07ba4fc248f14c0173d9b19179a.camel@tugraz.at>
Date: Thu, 27 Feb 2025 05:18:22 +0100
From: Martin Uecker <uecker@...raz.at>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ralf Jung <post@...fj.de>, "Paul E. McKenney" <paulmck@...nel.org>, 
 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)

Am Mittwoch, dem 26.02.2025 um 13:14 -0800 schrieb Linus Torvalds:
> On Wed, 26 Feb 2025 at 12:00, Martin Uecker <uecker@...raz.at> wrote:

[...]
> 
> That "single read done as multiple reads" is sadly still accepted by
> the C standard, as far as I can tell. Because the standard still
> considers it "unobservable" unless I've missed some update.
> 
> Please do better than that.

This is not really related to "observable" but to visibility
of stores to other threads.

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 does sound entirely resonable to me and if compilers
already do behave this way (though Paul's comment
seems to imply otherwise), then I think the standard
could easily be changed to ensure this.   I do some work to
remove UB and I was already thinking about what could
be done here.

But somebody would have to do the work and propose this. *)
Such a change would need to come with a precise enough
explanation what needs to change and a clear rationale.  

My guess is that if one could convince compiler people
- especially those from the clang side that are the most
critical in my experience - then such a proposal would
actually have a very good chance to be accepted.

There would certainly be opposition if this fundamentally
diverges from C++ because no compiler framework will seriously
consider implementing a completely different memory model
for C (or for Rust) than for C++.

I could also imagine that the problem here is that it is
actually very difficult for compilers to give the guarantess
you want, because they evolved from compilers
doing optimization for single threads and and one would
have to fix a lot of issues in the optimizers.  So the
actually problem here might be that nobody wants to pay
for fixing the compilers.

Martin

*): https://www.open-std.org/jtc1/sc22/wg14/www/contributing.html