[llvm-dev] retpoline mitigation and 6.0

[David Woodhouse via llvm-dev]

On Wed, 2018-02-07 at 13:16 -0800, Guenter Roeck wrote:

> Here are my exact versions:
>     llvm:	3afd566557f3 ("AMDGPU: Add 32-bit constant address space")
>     clang:	848874aed95a ("[clang-format] Fix ObjC message arguments formatting.")

OK, mine are slightly newer than that now, but I now get a working 64-
bit defconfig build. It'll still break with any PV guest support
enabled because we need %V asm constraint modifiers.

> PATH=${HOME}/src/clang/build/bin:${PATH}
> make CC=clang defconfig
> make CC=clang -j80
> 
> The build is a bit noisy right now due to 66f793099a63 ("x86/retpoline: Avoid
> retpolines for built-in __init functions"), since clang doesn't understand
> "__attribute__((indirect_branch("keep")))".

I fixed that (well, worked around it) in my tree.

> > > I can disable the i915 driver, but the "invalid output size for
> > > constraint '=q'" happens all over the place. Ultimately this means
> > > that I can not really test a 32-bit build, though it would not build
> > > anyway because it requires the following symbols
> > > 
> > > 	U __x86_indirect_thunk_esp
> > > 	U __x86_indirect_thunk
> >
> > The latter I can live with, as discussed, for 32-bit only. We don't
> > care about CET compatibility there, so I'm OK to implement the bare
> > ret-equivalent __x86_indirect_thunk.
> > 
> > The former... wtf? Can you show me the code that actually *calls* that.
> > I am having difficulty imagining any situation in which that's sane.
>
> Turns out this was PBKAC. That was with chromeos-4.14, which does not yet
> include the upstream patch removing __x86_indirect_thunk_esp. I don't
> see it with ToT. The "U" was from ./arch/x86/lib/lib-ksyms.o, meaning it
> was internally generated. Sorry for the noise.

OK... which __x86_indirect_thunk* symbols *are* being used by Clang in
32-bit mode? I've added __x86_indirect_thunk for 32-bit now, and if
that's *all* the Clang is using then I'll possibly switch GCC into that
mode too.

Can you take care of filing the tickets for %V0 and "=q"
and attribute__((indirect_branch("keep"))) please? With those fixed, I
think we should be OK again.
-------------- 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/20180207/0bec21d4/attachment-0001.bin>