llvm dev - Feb 2018 - retpoline mitigation and 6.0

On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse
wrote:
> On Wed, 2018-02-07 at 06:20 +0000, Chandler Carruth wrote:
> > I've landed the patch in r324449.
> > 
> > Before we merge this into two different Clang release branches and
> > almost immediately release one of them, I would really like someone
> > to confirm that this patch works well with the Linux kernel. David,
> > if you're up for that, it would be great. Alternatively, Guenter
or
> > someone else here can help.
> 
> 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.

When trying to build for ARCH=i386, I get

arch/x86/events/intel/../perf_event.h:767:21: error:
	invalid output size for constraint '=q'

and a clang crash when compiling drivers/gpu/drm/i915/i915_perf.c.

#0 0x0000000001ee982a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/local/google/home/groeck/src/clang/build/bin/clang-7.0+0x1ee982a)
#1 0x0000000001ee7a7e llvm::sys::RunSignalHandlers()
(/usr/local/google/home/groeck/src/clang/build/bin/clang-7.0+0x1ee7a7e)
#2 0x0000000001ee7bba SignalHandler(int)
(/usr/local/google/home/groeck/src/clang/build/bin/clang-7.0+0x1ee7bba)
#3 0x00002b7bcb485330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x0000000002727b04
llvm::DAGTypeLegalizer::PromoteIntOp_ATOMIC_STORE(llvm::AtomicSDNode*)
(/usr/local/google/home/groeck/src/clang/build/bin/clang-7.0+0x2727b04)

Linux: v4.15-11704-ga2e5790d8416
clang/llvm:
clang version 7.0.0 (https://git.llvm.org/git/clang.git/
848874aed95a913fb45f363120500cebfe54e2ef)
(https://git.llvm.org/git/llvm.git/3afd566557f3616881505db0d69f5d19bf55ae14)

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

which are both not available in the upstream kernel.

For x86_64, code generation appears to be as expected.
Next, I'll try to apply the patch on top of the Google toolchain
(based on llvm 6.0) and run it on a real system.

Guenter

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

> 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.
-------------- 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/9a7ad1d3/attachment.bin>

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