[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

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/9aa3b053/attachment.html>