Re: [PATCH 1/5] x86: Add -mindirect-branch=

[Jeff Law <law at redhat dot com>]

On 01/11/2018 04:07 PM, Jakub Jelinek wrote:
> On Thu, Jan 11, 2018 at 03:46:51PM -0700, Jeff Law wrote:
>> Note I'm expecting Uros to chime in.  So please do not consider this
>> ack'd until you hear from Uros.
>>
>> At a high level is there really that much value in having thunks in the
>> object file?  Why not put the full set of thunks into libgcc and just
>> allow selection between inline sequences and external thunks
>> (thunk-inline and thunk-external)?  It's not a huge simplification, but
>> if there isn't a compelling reason, let's drop the in-object-file thunks.
> 
> Not everything is linked against libgcc.a, something is linked against just
> libgcc_s.so.1, other stuff against both, some libraries against none of that.
> Probably it is undesirable to have the thunks at non-constant offsets from
> the uses, that would need text relocations.  Thunks emitted in the object
> files, hidden and comdat merged between .o files like what we have say for
> i686 PIC thunks seems like the best default to me and a way for the kernel
> to override that.
For things that don't link against libgcc, they would (of course) be
expected to provide the necessary thunks.  The kernel would be the
obvious example and that's precisely what they're going to do.

WRT text relocs, yea that sucks, but if we're going to have user space
mitigations, then we're likely going to need those relocs so that the
thunks can be patched out.  I'm actually hoping we're not going to need
user space mitigations for spectre v2 and we can avoid this problem..



I'm just not convinved there's a lot of value there, but I'm not going
to hold things up on that.  So I won't object on this basis.

jeff