On Fri, Jan 12, 2018 at 10:57:08AM -0700, Jeff Law wrote:
> 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..
Some architectures don't allow text relocations at all, including x86_64.
So any kind of runtime patching isn't that easy, and is generally a security
hole that e.g. SELinux prevents as well.
Jakub
