linux-kernel - Re: [RFC] tools/memory-model: Rule out OOTA

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] [day] [month] [year] [list]

Message-ID: <b77902dd-d17f-4e09-ac52-35a6ab1e78e5@rowland.harvard.edu>
Date: Wed, 22 Jan 2025 14:11:26 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc: paulmck@...nel.org, parri.andrea@...il.com, will@...nel.org,
	peterz@...radead.org, boqun.feng@...il.com, npiggin@...il.com,
	dhowells@...hat.com, j.alglave@....ac.uk, luc.maranget@...ia.fr,
	akiyks@...il.com, dlustig@...dia.com, joel@...lfernandes.org,
	urezki@...il.com, quic_neeraju@...cinc.com, frederic@...nel.org,
	linux-kernel@...r.kernel.org, lkmm@...ts.linux.dev,
	hernan.poncedeleon@...weicloud.com
Subject: Re: [RFC] tools/memory-model: Rule out OOTA

On Wed, Jan 22, 2025 at 04:46:03AM +0100, Jonas Oberhauser wrote:
> > > > > Yes. Actually I wonder if you put this "all loads are volatile" restriction,
> > > > > can a globally analysing compiler still have any optimizations that a
> > > > > locally analysing compiler can not?
> > > > 
> > > > Yes, although whether they are pertinent is open to question.  For
> > > > example, a globally optimizing compiler may observe that no thread ever
> > > > reads the value of a particular shared variable and then eliminate that
> > > > variable.
> > > 
> > > Oh, I meant the "all atomic objects is volatile" restriction, not just the
> > > loads. In that case, all stores the object - even if never read - still need
> > > to be generated.
> > > 
> > > Are there still any optimizations?
> > 
> > Perhaps not any that affect shared variable accesses.  In a way, that
> > was the intention.
> 
> Yes, but it becomes a bit strange then to treat the "globally analyzing
> compiler" as a harder problem. You have made a globally analyzing compiler
> that can not globally analyze. I understand that makes the argument
> feasible, but I am not sure if this is how compilers really behave (or at
> least will still behave in the future).

There's still an important difference.  A globally optimizing compiler 
is allowed to generate different object code for a thread (containing 
the same source code) in different programs, depending on the source for 
the other threads.  A locally analyzing compiler is not allowed to do 
this; it will always generate the same object code for threads 
containing the same source code, regardless of what the rest of the 
program does.

Alan