On 01/05/2018 03:47 AM, Richard Biener wrote:
> On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists)
> <richard.earns...@arm.com> wrote:
>> On 05/01/18 09:44, Richard Biener wrote:
>>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
>>> <richard.earns...@arm.com> wrote:
>>>>
>>>> Recently, Google Project Zero disclosed several classes of attack
>>>> against speculative execution. One of these, known as variant-1
>>>> (CVE-2017-5753), allows explicit bounds checks to be bypassed under
>>>> speculation, providing an arbitrary read gadget. Further details can
>>>> be found on the GPZ blog [1] and the documentation that is included
>>>> with the first patch.
>>>>
>>>> This patch set adds a new builtin function for GCC to provide a
>>>> mechanism for limiting speculation by a CPU after a bounds-checked
>>>> memory access. I've tried to design this in such a way that it can be
>>>> used for any target where this might be necessary. The patch set
>>>> provides a generic implementation of the builtin and then
>>>> target-specific support for Arm and AArch64. Other architectures can
>>>> utilize the internal infrastructure as needed.
>>>>
>>>> Most of the details of the builtin and the hooks that need to be
>>>> implemented to support it are described in the updates to the manual,
>>>> but a short summary is given below.
>>>>
>>>> TYP __builtin_load_no_speculate
>>>> (const volatile TYP *ptr,
>>>> const volatile void *lower,
>>>> const volatile void *upper,
>>>> TYP failval,
>>>> const volatile void *cmpptr)
>>>>
>>>> Where TYP can be any integral type (signed or unsigned char, int,
>>>> short, long, etc) or any pointer type.
>>>>
>>>> The builtin implements the following logical behaviour:
>>>>
>>>> inline TYP __builtin_load_no_speculate
>>>> (const volatile TYP *ptr,
>>>> const volatile void *lower,
>>>> const volatile void *upper,
>>>> TYP failval,
>>>> const volatile void *cmpptr)
>>>> {
>>>> TYP result;
>>>>
>>>> if (cmpptr >= lower && cmpptr < upper)
>>>> result = *ptr;
>>>> else
>>>> result = failval;
>>>> return result;
>>>> }
>>>>
>>>> in addition the specification of the builtin ensures that future
>>>> speculation using *ptr may only continue iff cmpptr lies within the
>>>> bounds specified.
>>>
>>> I fail to see how the vulnerability doesn't affect aggregate copies
>>> or bitfield accesses. The vulnerability doesn't cause the loaded
>>> value to leak but (part of) the address by populating the CPU cache
>>> side-channel.
>>>
>>
>> It's not quite as simple as that. You'll need to read the white paper
>> on Arm's web site to get a full grasp of this (linked from
>> https://www.arm.com/security-update).
>>
>>> So why isn't this just
>>>
>>> T __builtin_load_no_speculate (T *);
>>>
>>> ? Why that "fallback" and why the lower/upper bounds?
>>
>> Because, for Arm, we need to use both CSEL and CSDB (AArch64) in tandem
>> to restrict subsequent speculation, the CSEL needs a condition and the
>> compiler must not be able to optimize it away based on logical
>> reachability. The fallback is used for the other operand of the CSEL
>> instruction.
>
> But the condition could be just 'true' in the instruction encoding? That is,
> why do you do both the jump-around and the csel? Maybe I misunderstood
> the RTL you appear to generate. I'd have expected an UNSPEC to avoid
> the compiler messing up things.
>
>>>
>>> Did you talk with other compiler vendors (intel, llvm, ...?)?
>>
>> As stated we'll shortly be submitting similar patches for LLVM.
>
> How do you solve the aggregate load issue? I would imagine
> that speculating stores (by pre-fetching the affected cache line!)
> could be another attack vector? Not sure if any CPU speculatively
> does that (but I see no good reason why a CPU shouldn't do that).
Without going into details, I've speculated to the appropriate folks
that there's other vectors for these kinds of attacks, some more
exploitable than others. Attacking the cache via loads/stores is just
one instance of a class of problems IMHO.
I fully expect we'll be fighting this class of problems for a while.
This is just the tip of the iceberg.
Jeff
