On 09/01/18 13:27, Alexander Monakov wrote: > On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote: >> > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence >> > wouldn't work (applying CSEL to the address rather than loaded value), and >> > if it wouldn't, then ARM-specific lowering of the builtin can handle that >> > anyhow, right? (by spilling the pointer) >> >> The load has to feed /in/ to the csel/csdb sequence, not come after it. > > Again, I'm sorry, but I have to insist that what you're saying here > contradicts > the documentation linked from > https://developer.arm.com/support/security-update > The PDF currently says, in "Details of the CSDB barrier": > > Until the barrier completes: > 1) For any load, store, data or instruction preload, RW2, appearing in > program order *after the barrier* [...] > > 2) For any indirect branch (B2), appearing in program order > *after the barrier* [...] > > [...] the speculative execution of RW2/B2 does not influence the > allocations of entries in a cache [...] > > It doesn't say anything about the behavior of CSDB being dependent on > the loads > encountered prior to it. (and imho it doesn't make sense for a hardware > implementation to work that way)
Read condition 1 i) again. i) the conditional select instruction has a register data dependency on a load R1, that has been executed speculatively, for one of its input registers, and To be executed speculatively it must be *after* a predicted operation that has not yet resolved. Once it has resolved it is no-longer speculative, it's committed (one way or another). R. > >> As I explained to Bernd last night, I think this is likely be unsafe. >> If there's some control path before __builtin_nontransparent that allows >> 'predicate' to be simplified (eg by value range propagation), then your >> guard doesn't protect against the speculation that you think it does. >> Changing all the optimizers to guarantee that wouldn't happen (and >> guaranteeing that all future optimizers won't introduce new problems of >> that nature) is, I suspect, very non-trivial. > > But note that in that case the compiler could have performed the same > simplification in the original code as well, emitting straight-line > machine code > lacking speculatively executable parts in the first place. > > Alexander
