Re: [PATCH v3 7/7] x86/boot: Check that there are no runtime relocations

[Arvind Sankar]

On Wed, Jul 01, 2020 at 08:44:56AM +0200, Ard Biesheuvel wrote:
> On Wed, 1 Jul 2020 at 01:28, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
> >
> > On Tue, Jun 30, 2020 at 03:00:43PM -0700, Fangrui Song wrote:
> > > * Ard Biesheuvel
> > > > On Tue, 30 Jun 2020 at 01:34, Fangrui Song <maskray@xxxxxxxxxx> wrote:
> > >
> > > If the executable is purely static, it does not need to have PLT. All
> > > calls to a PLT can be redirected to the function itself.  Some range
> > > extension thunks (other terms: stub groups, veneers, etc) may still be
> > > needed if the distance is too large.
> > >
> > > There are cases where a GOT cannot be avoided, e.g.
> > >
> > > extern char foo[] __attribute__((weak, visibility("hidden")));
> > > char *fun() { return foo; }
> > >
> > > If foo is a SHN_ABS, `movq foo@GOTPCREL(%rip), %rax` can't be optimized
> > > by GOTPCRELX (https://sourceware.org/bugzilla/show_bug.cgi?id=25749 binutils>=2.35 will be good)
> > > Many other architectures don't even have a GOT optimization.
> >
> > Urk -- the example given in that bug report isn't even weak. Are you
> > guys proposing to pessimize every access to a global symbol, regardless
> > of visibility, by going through the GOT on the off chance that somebody
> > might define one of them as SHN_ABS? Can we at least gate it behind
> > something like __attribute__((might_be_shn_abs))?
> >
> 
> SHN_ABS is typically only used for constants emitted by the linker
> script, so I don't think this is a huge deal.
> 
> The example above is not that different from having a statically
> initialized function pointer in your object (which might be NULL), and
> that is something we already have to deal with anyway.
> 
> What I was talking about is the tendency of the compiler to assume
> that every function symbol with external linkage is preemptible, and
> the only way to suppress this behavior is to issue a #pragma that can
> be done in code only, not on the compiler command line.
> 

Yes, SHN_ABS is rare. But supporting it without an explicit annotation
for the compiler requires pessimizing the common case where the symbol
is _not_ SHN_ABS, because the compiler would have to assume that
everything might be defined as SHN_ABS. This includes accessing a simple
extern int variable.

It would have to generate the GOT-referencing code in all cases where it
doesn't see a strong definition, even with hidden visibility. And on
x86, we'd have to bump the toolchain requirement to at least 2.26 so we
can get the linker relaxations, otherwise you'd have GOT references in
the final code.