[RFD] How legal is it to delete dynamic tags?

[RFD] How legal is it to delete dynamic tags?

[Matthew Fortune]

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?

Thanks for any insight you can offer.

Matthew

Re: [RFD] How legal is it to delete dynamic tags?

[Alan Modra]

On Fri, Apr 15, 2016 at 03:08:41PM +0000, Matthew Fortune wrote:
> Firstly, to what extent is it OK to just delete a dynamic tag rather
> than set it to DT_NULL?

DT_NULL marks the end of the dynamic tags array.  Setting a tag to
DT_NULL is not an option (except when the following tag is DT_NULL).
You'll break ld.so if you do that.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [RFD] How legal is it to delete dynamic tags?

[Nathaniel Smith]

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.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

Re: [RFD] How legal is it to delete dynamic tags?

[Nathaniel Smith]

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

RE: [RFD] How legal is it to delete dynamic tags?

[Matthew Fortune]

Alan Modra <amodra@gmail.com> writes:
> On Fri, Apr 15, 2016 at 03:08:41PM +0000, Matthew Fortune wrote:
> > Firstly, to what extent is it OK to just delete a dynamic tag rather
> > than set it to DT_NULL?
> 
> DT_NULL marks the end of the dynamic tags array.  Setting a tag to
> DT_NULL is not an option (except when the following tag is DT_NULL).
> You'll break ld.so if you do that.

Thanks. I had some vague memory that DT_NULL couldn't be used arbitrarily
but couldn't think why.

Matthew

RE: [RFD] How legal is it to delete dynamic tags?

[Matthew Fortune]

Nathaniel Smith <njs@pobox.com> writes:
> 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/patche
> lf.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 :-).

Thanks Nathaniel,

I didn't know about patchelf either so I'll see if I can get it updated
similarly to chrpath.

Matthew