Question about EI_ABIVERSION handling

Question about EI_ABIVERSION handling

[Dragan Mladjenovic]

Hi all,

Apologies to the recipients who received this message more than once.

While I was trying to update an old MIPS PT_GNU_STACK proposal [1] in time for the new ABI
freeze I've noticed an oddity in handling of EI_ABIVERSION field.

It seems that ld.so does not validate EI_ABIVERSION of main executable when the said
executable is loaded directly by the kernel. 
I does do so if ld.so is run as a command and then loads the main executable by itself.

Is this behavior intended? If I would wish to ensure that executable with newer ABI
version get rejected by the old loaders, am I expected to add some other incompatible change like
new dynamic tag? 
    
[1] https://sourceware.org/ml/libc-alpha/2016-02/msg00076.html

Best regards,

Dragan

Re: Question about EI_ABIVERSION handling

[Florian Weimer]

* Dragan Mladjenovic:

> It seems that ld.so does not validate EI_ABIVERSION of main executable
> when the said executable is loaded directly by the kernel.

Hmm.  I think this may be an oversight.  I can confirm this behavior on
x86-64.

> Is this behavior intended? If I would wish to ensure that executable
> with newer ABI version get rejected by the old loaders, am I expected
> to add some other incompatible change like new dynamic tag?

Unknown dynamic tags are ignored (like unknown program headers).  Only
unknown relocation types result in errors.

Thanks,
Florian

Re: Question about EI_ABIVERSION handling

[Szabolcs Nagy]

On 26/06/2019 13:01, Florian Weimer wrote:
> * Dragan Mladjenovic:
> 
>> It seems that ld.so does not validate EI_ABIVERSION of main executable
>> when the said executable is loaded directly by the kernel.
> 
> Hmm.  I think this may be an oversight.  I can confirm this behavior on
> x86-64.
> 
>> Is this behavior intended? If I would wish to ensure that executable
>> with newer ABI version get rejected by the old loaders, am I expected
>> to add some other incompatible change like new dynamic tag?
> 
> Unknown dynamic tags are ignored (like unknown program headers).  Only
> unknown relocation types result in errors.

unknown dynamic relocation can be an intrusive change,
it requires a location (which can cause problems if the
same location has multiple relocations) and many tools
may need to be updated, not just the dynamic linker to
support it.

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)

Re: Question about EI_ABIVERSION handling

[Carlos O'Donell]

On 6/26/19 9:13 AM, Szabolcs Nagy wrote:
> On 26/06/2019 13:01, Florian Weimer wrote:
>> * Dragan Mladjenovic:
>>
>>> It seems that ld.so does not validate EI_ABIVERSION of main executable
>>> when the said executable is loaded directly by the kernel.
>>
>> Hmm.  I think this may be an oversight.  I can confirm this behavior on
>> x86-64.
>>
>>> Is this behavior intended? If I would wish to ensure that executable
>>> with newer ABI version get rejected by the old loaders, am I expected
>>> to add some other incompatible change like new dynamic tag?
>>
>> Unknown dynamic tags are ignored (like unknown program headers).  Only
>> unknown relocation types result in errors.
> 
> unknown dynamic relocation can be an intrusive change,
> it requires a location (which can cause problems if the
> same location has multiple relocations) and many tools
> may need to be updated, not just the dynamic linker to
> support it.
> 
> 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.
~~~



-- 
Cheers,
Carlos.

Re: Question about EI_ABIVERSION handling

[Maciej W. Rozycki]

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