This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Question about EI_ABIVERSION handling
On Wed, 26 Jun 2019, Carlos O'Donell wrote:
> > an alternative is a known dynamic relocation with undefined
> > symbol reference. (a new libc provides the symbol, an old
> > libc fails), unfortunately this seems hard to do for linker
> > features (hard coding magic symbol refs at link-time seems
> > wrong, conditionally linking a .o provided by the libc when
> > a particular link feature is used would work, but there is
> > no such mechanism currently)
> >
>
> I thought we had such checking because we used it for Maciej's
> work here?
>
> ~~~
> * The GNU C Library now has correct support for ABSOLUTE symbols
> (SHN_ABS-relative symbols). Previously such ABSOLUTE symbols were
> relocated incorrectly or in some cases discarded. The GNU linker can
> make use of the newer semantics, but it must communicate it to the
> dynamic loader by setting the ELF file's identification (EI_ABIVERSION
> field) to indicate such support is required.
> ~~~
Ouch, I think the need to check the value of EI_ABIVERSION requested by
the main executable has been overlooked. And I have not noticed it or
addressed with my fix for ABSOLUTE symbols either, clearly by relying on
explicit `ld.so' invocation too much. It does not matter for the ABSOLUTE
symbol feature in ordinary executables, however it does for PIE.
The main executable's ELF file header does not appear to be processed,
which is why in the proposed MIPS NaN interlinking patch series I added an
extra hook, `elf_machine_main_map_setup', exactly for this purpose with
<https://sourceware.org/ml/libc-alpha/2015-11/msg00487.html> ("ELF: Add
machine-dependent main link map setup hook"), and then used it with
<https://sourceware.org/ml/libc-alpha/2015-11/msg00490.html> ("MIPS: Add
IEEE Std 754 NaN interlinking support").
Strictly speaking a machine-specific hook would be needed anyway, however
it would be called from or around the place where generic ELF file header
processing would be arranged to take place for the main executable.
Futhermore it looks to me like we actually have no reliable way to
process the ELF file header of the main executable as we are only passed
information about the main executable from the kernel via the auxiliary
vector and there is no entry defined for a pointer the ELF file header,
there's only AT_PHDR for the program headers. We might have to extend the
auxiliary vector's protocol, to have either AT_EHDR or at the very least
AT_ABIVERSION communicated there, so as to be able to do such processing.
While there is the AT_EXECFN entry holding the main executable's name we
could use, I think it is insecure or at least unsafe as the link to the
file could be renamed or deleted (and substituted with a link to another
file) in the time between the moment the auxiliary vector is prepared by
the kernel and the point the vector is examined by the interpreter.
Oh well...
Maciej