Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

[Jeff Law <law at redhat dot com>]

On 07/10/2018 08:14 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 14:48, Bill Schmidt wrote:
>>
>>> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
>>>
>>> On 10/07/18 00:13, Jeff Law wrote:
>>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>>>
>>>>> The patches I posted earlier this year for mitigating against
>>>>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
>>>>> which it became obvious that a rethink was needed.  This mail, and the
>>>>> following patches attempt to address that feedback and present a new
>>>>> approach to mitigating against this form of attack surface.
>>>>>
>>>>> There were two major issues with the original approach:
>>>>>
>>>>> - The speculation bounds were too tightly constrained - essentially
>>>>>  they had to represent and upper and lower bound on a pointer, or a
>>>>>  pointer offset.
>>>>> - The speculation constraints could only cover the immediately preceding
>>>>>  branch, which often did not fit well with the structure of the existing
>>>>>  code.
>>>>>
>>>>> An additional criticism was that the shape of the intrinsic did not
>>>>> fit particularly well with systems that used a single speculation
>>>>> barrier that essentially had to wait until all preceding speculation
>>>>> had to be resolved.
>>>> Right.  I suggest the Intel and IBM reps chime in on the updated semantics.
>>>>
>>>
>>> Yes, logically, this is a boolean tracker value.  In practice we use ~0
>>> for true and 0 for false, so that we can simply use it as a mask
>>> operation later.
>>>
>>> I hope this intrinsic will be even more acceptable than the one that
>>> Bill Schmidt acked previously, it's even simpler than the version we had
>>> last time.
>>
>> Yes, I think this looks quite good.  Thanks!
>>
>> Thanks also for digging into the speculation tracking algorithm.  This
>> has good potential as a conservative opt-in approach.  The obvious
>> concern is whether performance will be acceptable even for apps
>> that really want the protection.
>>
>> We took a look at Chandler's WIP LLVM patch and ran some SPEC2006 
>> numbers on a Skylake box.  We saw geomean degradations of about
>> 42% (int) and 33% (fp).  (This was just one test, so caveat emptor.)
>> This isn't terrible given the number of potential false positives and the
>> early state of the algorithm, but it's still a lot from a customer perspective.
>> I'll be interested in whether your interprocedural improvements are
>> able to reduce the conservatism a bit.
>>
> 
> So I don't have any numbers for SPEC2006.  I have some initial numbers
> for SPEC2000 when just adding the tracking code (so not applying the
> second part of the mitigation).  In that case INT2000 is down by ~13%
> and FP2000 was by comparison almost in the noise (~2.4%).
> 
> Applying the tracker value to all memory loads would push those numbers
> up significantly, I suspect.  That's part of the reason for preferring
> the intrinsic rather than automatic mitigation: the intrinsic is much
> more targeted.
Right.  Fully automatic without any "hints" is going to be very
expensive, possibly prohibitively expensive.

Using the intrinsic or exploiting some kind of taint analysis has the
potential to drastically reduce the overhead.  At least it seems like
they should :-)

jeff