[llvm-dev] retpoline mitigation and 6.0

[Guenter Roeck via llvm-dev]

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