[llvm-dev] retpoline mitigation and 6.0

[David Woodhouse via llvm-dev]

On Fri, 2018-02-09 at 08:45 +0000, Chandler Carruth wrote:
> > 
> > You're pushing the target (-0x20(%ebp)) onto the stack and then
> > *calling* __x86_indirect_thunk. So it looks like you're expecting
> > __x86_indirect_thunk to do something like
> > 
> >   call *4(%esp)
> >   ret
> > 
> > ... except that final 'ret' still leaves the target address on the
> > stack, so there would also need to be a complicated dance, without
> > using any registers, to pop that too.
>
> Yeah, we expect a complicated dance to re-order the stack to get the
> correct return address into the correct place.
> 
> You can see the sequence in the comments here:
> https://github.com/llvm-project/llvm-project-20170507/blob/master/llvm/lib/Target/X86/X86RetpolineThunks.cpp#L179-L194

Great, thanks.

> Anyways, it appears that we have the first case where my suspicions
> were borne out and we have somewhat reasonably different ABIs for
> some of the thunks.
> 
> How should we name them to distinguish things? 

For now it's only ever going to be used by LLVM so you can call it what
you like, although if do want to bring GCC in line to use it too then
perhaps it should be a more functional name and not explicitly mention
llvm? I don't know how weird GCC people would get if you ask them to
implement stuff that has 'llvm' in the name... :)

Did you get anywhere with the function attribute? Having isolated the
next boot failure to "it goes away if I compile io_apic.c without
retpoline", bisecting it per-function would help to further delay the
bit where I actually have to start *thinking*...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/fbcb1814/attachment.bin>