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
| ||
|
Date: Tue, 6 Oct 2020 16:43:02 +0200 From: Peter Zijlstra <peterz@...radead.org> To: "stern@...land.harvard.edu" <stern@...land.harvard.edu> Cc: David Laight <David.Laight@...lab.com>, "linux-toolchains@...r.kernel.org" <linux-toolchains@...r.kernel.org>, Will Deacon <will@...nel.org>, Paul McKenney <paulmck@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "parri.andrea@...il.com" <parri.andrea@...il.com>, "boqun.feng@...il.com" <boqun.feng@...il.com>, "npiggin@...il.com" <npiggin@...il.com>, "dhowells@...hat.com" <dhowells@...hat.com>, "j.alglave@....ac.uk" <j.alglave@....ac.uk>, "luc.maranget@...ia.fr" <luc.maranget@...ia.fr>, "akiyks@...il.com" <akiyks@...il.com>, "dlustig@...dia.com" <dlustig@...dia.com>, "joel@...lfernandes.org" <joel@...lfernandes.org>, "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org> Subject: Re: Control Dependencies vs C Compilers On Tue, Oct 06, 2020 at 10:23:24AM -0400, stern@...land.harvard.edu wrote: > On Tue, Oct 06, 2020 at 03:31:15PM +0200, Peter Zijlstra wrote: > > Only if we get the compiler people on board and have them provide means > > are we guaranteed safe from the optimizer. Otherwise we'll just keep > > playing whack-a-mole with fancy new optimization techniques. And given > > how horridly painful it is to debug memory ordering problems, I feel it > > is best to make sure we're not going to have to more than necessary. > > Given that you would have to add a compiler annotation, isn't it just as > easy to use READ_ONCE and WRITE_ONCE? > > Or are you worried that even with READ_ONCE and WRITE_ONCE, the compiler > might still somehow defeat the control dependency? Yes. Also, not all instances actually have the WRITE_ONCE() on. The one in the perf ringbuffer for example uses local_read() for the load (which is basically READ_ONCE()), but doesn't have WRITE_ONCE() on the inside. Also, afaiu WRITE_ONCE() also doesn't stop the compiler from lifting it if it thinks it can get away with it -- memory-barriers.txt has examples. And then there's the case where the common branch has a store, I know ARM64 ARM isn't clear on that, but I'm thinking any actual hardware will still have to respect it, and it's a matter of 'fixing' the ARM. Mostly I just want the compiler people to say they'll guarantee the behaviour if we do 'X'. If 'X' happens to be 'any dynamic branch headed by a volatile load' that's fine by me. If they want a new keyword or attribute, that's also fine. But I want to have the compiler people tell me what they want and guarantee they'll not come and wreck things.
Powered by blists - more mailing lists