This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFD] How legal is it to delete dynamic tags?
- From: Nathaniel Smith <njs at pobox dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>, Anibal Monsalve Salazar <Anibal dot MonsalveSalazar at imgtec dot com>
- Date: Fri, 15 Apr 2016 16:17:00 -0700
- Subject: Re: [RFD] How legal is it to delete dynamic tags?
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023537E3D685D at hhmail02 dot hh dot imgtec dot org> <CAPJVwBkWXtJSanSke4YXT9VsxB+=KYM3V4HQAfqWT_me=EgV0Q at mail dot gmail dot com>
On Fri, Apr 15, 2016 at 4:13 PM, Nathaniel Smith <njs@pobox.com> wrote:
> On Fri, Apr 15, 2016 at 8:08 AM, Matthew Fortune
> <Matthew.Fortune@imgtec.com> wrote:
>> I have a bug report from Debian showing that the DT_MIPS_RLD_MAP_REL
>> tag (introduced on MIPS to support shared library debug with PIE)
>> can be corrupted by a program called chrpath.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818909#43
>>
>> chrpath is designed to alter or remove DT_RPATH entries. Removal is
>> a problem when such an entry precedes DT_MIPS_RLD_MAP_REL as the
>> relative offset stored in DT_MIPS_RLD_MAP_REL then points to the
>> wrong address.
>>
>> Firstly, to what extent is it OK to just delete a dynamic tag rather
>> than set it to DT_NULL?
>>
>> Secondly was it a bad decision to create a slot-relative dynamic
>> tag? I.e. If I were to fix chrpath to know that DT_MIPS_RLD_MAP_REL
>> needs updating... are there likely to be more utilities out there
>> that fiddle with dynamic tags in this way?
>
> There's patchelf at least, which is like a fancier version of chrpath:
>
> https://github.com/NixOS/patchelf
>
> So it probably has the same bug when deleting DT_RPATH / DT_RUNPATH /
> DT_NEED entries. Also, some of patchelf's operations add new entries
> to the dynamic tag table (e.g. adding a new DT_RUNPATH or DT_NEED
> entry), which I think ends up involving larger rearrangements of the
> file (e.g. moving the whole table to somewhere else where there's room
> to expand it); it's likely that this might cause problems for your
> slot-relative tag as well.
Actually, it looks like in some cases (but not all), patchelf deletes
entries from the dynamic tag table by leaving them their but setting
their type to a magic "DT_IGNORE" value:
https://github.com/NixOS/patchelf/blob/77efcf2f2d2f95391a6717cc9457f87267500e72/src/patchelf.cc#L222-223
No idea if this DT_IGNORE thing has any precedent in the ELF spec
(google doesn't seem to find any references to it outside of the
patchelf source), but apparently it works in practice. You still have
the problems that patchelf doesn't use it consistently, chrpath
doesn't use it at all, and that there are other cases where patchelf
needs to move DT entries, but I guess using this DT_IGNORE thing would
work to solve the narrow chrpath problem that started the thread :-).
-n
--
Nathaniel J. Smith -- https://vorpus.org