linux-kernel - Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion

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]

Date:   Thu, 9 Nov 2023 12:09:11 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Boqun Feng <boqun.feng@...il.com>
Cc:     Jonas Oberhauser <jonas.oberhauser@...weicloud.com>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Peter Zijlstra <peterz@...radead.org>, j.alglave@....ac.uk,
        will@...nel.org, catalin.marinas@....com, linux@...linux.org.uk,
        mpe@...erman.id.au, npiggin@...il.com, palmer@...belt.com,
        parri.andrea@...il.com, linux-kernel@...r.kernel.org,
        linux-toolchains@...r.kernel.org, davidtgoldblatt@...il.com
Subject: Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load)
 discussion

On Thu, Nov 09, 2023 at 10:24:23AM -0800, Boqun Feng wrote:
> On Thu, Nov 09, 2023 at 05:25:05PM +0100, Jonas Oberhauser wrote:
> [...]
> > > 4.	Semantics of volatile.	Perhaps the current state is the best
> > > 	that can be hoped for, but given that the current state is a
> > > 	few vague words in the standard in combination with the fact
> > > 	that C-language device drivers must be able to use volatile
> > > 	to reliably and concurrently access memory shared with device
> > > 	firmware, one would hope for better.
> > 
> > 
> > Is it really so bad? I think the definition in the manual is quite precise,
> > if confusing. (volatiles are visible side effects and must therefore have
> > the same program order in the abstract machine and in the implementation,
> > and that's pretty much it).
> 
> But I don't think there is any mention on whether current volatile
> accesses can be excluded from data race, or whether a volatile access
> on a machine-word size natually aligned object can be teared or not.

Here is my understanding:  It must be possible to write C-language
device drivers for devices that...

1.	read and write to normal memory.  If this device has C-langugae
	firmware, volatile reads and writes involving aligned
	machine-word-sized locations must not invoke undefined behavior.

2.	allow concurrent reads and writes to MMIO registers (or to
	normal memory).  Even ignoring the device firmware, volatile
	reads and writes involving aligned machine-word-sized locations
	must not invoke undefined behavior.

Not necessarily a popular view, but then again, in my experience,
objective reality never has been trying to win a popularity contest.

							Thanx, Paul

> Regards,
> Boqun
> 
> > There should just be a large explanatory note about what it implies and what
> > it doesn't imply.
> > 
> >