Re: Question about EI_ABIVERSION handling

[Carlos O'Donell <carlos at redhat dot com>]

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.