[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

The patch is up for review here: https://reviews.llvm.org/D42998

On Tue, Feb 6, 2018 at 4:58 PM Chandler Carruth <chandlerc at google.com>
wrote:

> Also, could you patch and test Clang with the Linux kernel after I make
> this change? I'd like to know that we actually successfully call the
> correct thunks and that they behave correctly. I'm not super worried, but
> good to  actually get this right. I'm am slightly more worried about the
> stack-based retpoline than the register ones just due to the overall lower
> amount of testing we've had there.
>
> On Tue, Feb 6, 2018 at 4:56 PM Chandler Carruth <chandlerc at google.com>
> wrote:
>
>> On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org>
>> wrote:
>>
>>> On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote:
>>>
>>> > >
>>> > > That would be __x86_indirect_thunk but the kernel doesn't use it.
>>> > > We use -mindirect-branch-register and only ever expect the compiler
>>> > > to use the register versions which are CET-compatible.
>>> > >
>>> > > However, in at least one case in the 32-bit kernel we do emit the
>>> > > old ret-equivalent retpoline inline, because there literally wasn't
>>> > > a single register we could use (yay x86).
>>> > >
>>> > > I would definitely consider ditching our use of -mindirect-thunk-
>>> > > register with GCC for 32-bit and exporting the
>>> > > __x86_indirect_thunk, to be consistent if that's what clang wants
>>> > > to do.
>>> > >
>>> > :: sigh :: is there no way to change the name?
>>> >
>>> > We use a "push" suffix to reduce ambiguity about what convention is
>>> > expected here.... But I guess we can just use the base name if that's
>>> > already shipped.
>>>
>>> It has indeed already shipped in GCC 7.3; sorry. It had no
>>> disambiguation in its name because it was the original retpoline,
>>> before we realised that CET would break things.
>>>
>>> The other thing to keep an eye on is the *return* thunk, which might
>>> end up being needed on Skylake-era CPUs. See the thread at
>>> https://lkml.org/lkml/2018/2/4/147
>>
>>
>> I'm strongly of the opinion that I think Arjan expressed:
>>
>> - retpoline alone is probably fine with sufficient RSB stuffing patches
>> in the kernel
>> - if some folks are worried about the security risk here and running on
>> SKX, they should use IBRS.
>>
>> Given the speed of IBRS on SKX and the complexity & runtime hit of
>> thunking ret, I really don't see a good motivation for us teaching the
>> compiler how to do this.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/0041690f/attachment.html>