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: <1fec6b96-8aae-4bda-8daf-892247882885@paulmck-laptop>
Date: Wed, 26 Feb 2025 11:01:51 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ralf Jung <post@...fj.de>, 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)

On Wed, Feb 26, 2025 at 09:59:41AM -0800, Linus Torvalds wrote:
> On Wed, 26 Feb 2025 at 05:54, Ralf Jung <post@...fj.de> wrote:
> >
> >      The only approach we know that we can actually
> > pull through systematically (in the sense of "at least in principle, we can
> > formally prove this correct") is to define the "visible behavior" of the source
> > program, the "visible behavior" of the generated assembly, and promise that they
> > are the same.
> 
> That's literally what I ask for with that "naive" code generation, you
> just stated it much better.
> 
> I think some of the C standards problems came from the fact that at
> some point the standards people decided that the only way to specify
> the language was from a high-level language _syntax_ standpoint.
> 
> Which is odd, because a lot of the original C semantics came from
> basically a "this is how the result works". It's where a lot of the
> historical C architecture-defined (and undefined) details come from:
> things like how integer division rounding happens, how shifts bigger
> than the word size are undefined, etc. But most tellingly, it's how
> "volatile" was defined.
> 
> I suspect that what happened is that the C++ people hated the volatile
> definition *so* much (because of how they changed what an "access"
> means), that they then poisoned the C standards body against
> specifying behavior in terms of how the code *acts*, and made all
> subsequent C standards rules be about some much more abstract
> higher-level model that could not ever talk about actual code
> generation, only about syntax.

Yes, they really do seem to want something that can be analyzed in a
self-contained manner, without all of the mathematical inconveniences
posed by real-world hardware.  :-(

> And that was a fundamental shift, and not a good one.
> 
> It caused basically insurmountable problems for the memory model
> descriptions. Paul McKenney tried to introduce the RCU memory model
> requirements into the C memory model discussion, and it was entirely
> impossible. You can't describe memory models in terms of types and
> syntax abstractions. You *have* to talk about what it means for the
> actual code generation.

My current thought is to take care of dependency ordering with our
current coding standards combined with external tools to check these
[1], but if anyone has a better idea, please do not keep it a secret!

							Thanx, Paul

[1] https://people.kernel.org/paulmck/the-immanent-deprecation-of-memory_order_consume