[PATCH] Allow direct access relocations referencing a protected function symbol

[Michael Matz]

Hello,

On Mon, 14 Jun 2021, Alan Modra via Binutils wrote:

> On Sun, Jun 13, 2021 at 02:54:00PM -0700, Fangrui Song via Binutils wrote:
> > This fixes the bogus "relocation R_* against protected symbol `foo'
> > can not be used when making a shared object" for function symbols for
> > at least aarch64/i386/x86-64.
> > 
> > The controversial "copy relocations on protected data symbols" (which has some
> > fragile glibc support) is irrelevant to function symbols.
> 
> No, this patch doesn't do that.  What you are doing here will disable
> dynamic relocations on protected function symbols in shared libraries.
> That will break function pointer comparison for architectures that
> implement non-pic executables, where a function that is undefined in
> the executable is given a fixed address in the executable, that of its
> plt call code.

Correct.  But I'm oscillating between thinking that this would be a 
problem and thinking the opposite :-/

One could always say that function addresses of protected functions aren't 
comparable.  Taking an address and using it as indirect call target will 
always work, you just wouldn't be able to compare them usefully.  Or one 
could require address references from outside components to a protected 
(function) symbol to always be via a GOT(-like structure).

Or (the other extremum of my oscillations) one says that function address 
comparisons absolutely need to work even in absence of 
indirection-via-GOT, at which point we basically talk about the same 
problem like protected data symbols and copy relocations.  If you then 
don't have relocations differing between calls and address taking, you 
effectively throw out the usefullness of protected visibility.

The problem with the latter stance is that it's not really justifiable 
from the ELF gABI: nothing says that getting at "the" function address 
must be possible without a GOT indirection.

(Adding to that is that what actually works in practice changed over time 
and depends on the architecture (and well, yeah, compiler and linker) so 
that now it's impossible to say "look there, that's how it should work 
and how everyone expects it to work" :-/ )


Ciao,
Michael.