Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Jan 11, 2018 at 2:16 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Jan 11, 2018 at 1:18 AM, Jeff Law <law@redhat.com> wrote:
>> On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
>>> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
>>>> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>>>>>> It's really just a couple of new primitives to emit a jump as a call and
>>>>>> one to slam in a new return address.  Given those I think you can do the
>>>>>> entire implementation as RTL at expansion time and you've got a damn
>>>>>> good shot at protecting most architectures from these kinds of attacks.
>>>>>
>>>>> I think that you're a bit optimistic here and that implementing a generic and
>>>>> robust framework at the RTL level might require some time.  Given the time and
>>>>> (back-)portability constraints, it might be wiser to rush into architecture-
>>>>> specific countermeasures than to rush into an half-backed RTL framework.
>>>>
>>>> Let me also say that while it might be nice to commonize code introducing these
>>>> mitigations as late as possible to not disrupt optimization is important.  So I
>>>> don't see a very strong motivation in trying very hard to make this more
>>>> middle-endish, apart from maybe sharing helper functions where possible.
>>>
>>> That and perhaps a common option to handle the cases that are common to
>>> multiple backends (i.e. move some options from -m* namespace to -f*).
>>> I'd say the decision about the options and ABI of what we emit is more
>>> important than where we actually emit it, we can easily change where we do
>>> that over time, but not the options nor the ABI.
>> From a UI standpoint, I think the decision has already been made as LLVM
>> has already thrown -mretpolines into their tree.   Sigh.
>
> Well, given retpolines are largely kernel relevant right now we don't
> need to care here.
>
>> So I think the one thing we ought to seriously consider is at least
>> reserving -mretpoline for this style of mitigation of spectre v2.  ALl
>> target's don't have to implementation this style mitigation, but if they
>> do, they use -mretpoline.
>
> And I'd also like people not to bikeshed too much on this given we're
> in the situation
> of having exploitable kernels around for which we need a cooperating
> compiler.  So
> during the time we bikeshed this (rather than reviewing the actual
> patches) we have
> to "backport" the current non-upstream state anyway to deliver fixed
> kernels to our
> customer.
>
> Yes, if this were a "normal feature" we could continue discussing and
> trying to design
> sth nice and shiny.  But this isn't a normal feature.
>
> So please - I'd also like to get this into a released compiler (aka
> 7.3) as soon as possible
> (given a RC for 7.3 was scheduled to be early this week).

Hi Uros,

Can you take a look at my x86 backend changes so that they are ready
to check in once we have consensus.

Thanks.

-- 
H.J.