Displaying 6 results from an estimated 6 matches for "__x86_indirect_thunk_esp".
2018 Feb 07
0
retpoline mitigation and 6.0
...gt; 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 dif...
2018 Feb 07
2
retpoline mitigation and 6.0
...6881505db0d69f5d19bf55ae14)
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
2018 Feb 07
3
retpoline mitigation and 6.0
...5 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 act...
2018 Feb 07
0
retpoline mitigation and 6.0
...nvalid 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?...
2018 Feb 07
0
retpoline mitigation and 6.0
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
2018 Feb 07
6
retpoline mitigation and 6.0
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.
On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth