On 08/01/18 14:19, Bill Schmidt wrote: > >> On Jan 7, 2018, at 10:47 PM, Jeff Law <l...@redhat.com> wrote: >> >> On 01/07/2018 07:20 PM, Bill Schmidt wrote: >>> Hi Richard, >>> >>> Unfortunately, I don't see any way that this will be useful for the ppc >>> targets. We don't >>> have a way to force resolution of a condition prior to continuing >>> speculation, so this >>> will just introduce another comparison that we would speculate past. For >>> our mitigation >>> we will have to introduce an instruction that halts all speculation at that >>> point, and place >>> it in front of all dangerous loads. I wish it were otherwise. >> So could you have an expander for __builtin_load_no_speculate that just >> emits the magic insn that halts all speculation and essentially ignores >> the additional stuff that __builtin_load_no_speculate might be able to >> do on other platforms? > > This is possible, but the builtin documentation is completely misleading for > powerpc. We will not provide the semantics that this builtin claims to > provide. > So at a minimum we would need the documentation to indicate that the > additional > range-checking is target-specific behavior as well, not just the speculation > code. > At that point it isn't really a very target-neutral solution. > > What about other targets? This builtin seems predicated on specific behavior > of ARM architecture; I don't know whether other targets have a guaranteed > speculation-rectifying conditional test. > > For POWER, all we would need, or be able to exploit, is > > void __builtin_speculation_barrier () > > or some such. If there are two dangerous loads in one block, a single call > to this suffices, but a generic solution involving range checks for specific > loads would require one per load. >
Do you have any data to suggest that multiple /independent/ vulnerable accesses occur under a single guarding condition more often than 'once in a blue moon'? It seems to me that would be highly unlikely. R.
