[llvm-dev] retpoline mitigation and 6.0

Guenter Roeck via llvm-dev
2018-02-07T21:16:19Z

On Wed, Feb 07, 2018 at 08:44:32PM +0000, David Woodhouse
wrote:
> On Wed, 2018-02-07 at 10:11 -0800, Guenter Roeck wrote:
>
> > On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote:
> > > Hm, please could we also have the %V asm constraint modifier?
That
> > > allows us to emit calls to the thunks from inline asm using the
> > > register that the compiler chose for us:
> > >
> > >  asm volatile ("call
__x86_indirect_thunk_%V[thunk_target]" : :
> > > 		[thunk_target] "r" (the_function));
> > >
> > > Other than that, I get the following errors with LLVM+Clang
master, and
> > > my tree at
> > >
http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb
> > >
> > I tried ToT clang with Linux upstream as well as chromeos-4.14,
> > with 'defconfig'. I don't see any errors when building
x86_64.
> > Lots and lots of warnings, though.
>
> The defconfig doesn't build here either; it still includes the cpuidle
> bits which don't build. I'll update LLVM/clang and try again, in
case
> it was fixed between your attempt and mine...
>

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

I used cmake-3.10.2, and the following commands:
    mkdir build
    cd build
    ../cmake-3.10.2/bin/cmake -DCMAKE_BUILD_TYPE=Release -G "Unix
Makefiles" ../llvm
    make -j80

To build the kernel:

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 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.

Guenter