Re: [PATCH 1/3] [builtins] Generic support for __builtin_load_no_speculate()

[Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>]

On Jan 8, 2018, at 9:23 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
> On 08/01/18 14:19, Bill Schmidt wrote:
>> 
>>> On Jan 7, 2018, at 10:47 PM, Jeff Law <law@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.

No, I agree with that.

This is more thinking ahead about the problem of trying to identify these
cases automatically.  Anything we do there is going to be necessarily 
conservative, so more loads may look dangerous than a human user can 
identify.  But for something like that then you probably aren't looking at
using __builtin_load_no_speculate anyhow.

Thanks,
Bill

> 
> 
> R.