public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nathaniel Smith <njs@pobox.com>
To: Matthew Fortune <Matthew.Fortune@imgtec.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
		Anibal Monsalve Salazar <Anibal.MonsalveSalazar@imgtec.com>
Subject: Re: [RFD] How legal is it to delete dynamic tags?
Date: Fri, 15 Apr 2016 23:17:00 -0000	[thread overview]
Message-ID: <CAPJVwBn6AxN9vB_G=wmmR+zZCg8Yh5j_=FaxcFNVxmRN4ZmMrQ@mail.gmail.com> (raw)
In-Reply-To: <CAPJVwBkWXtJSanSke4YXT9VsxB+=KYM3V4HQAfqWT_me=EgV0Q@mail.gmail.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

  reply	other threads:[~2016-04-15 23:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15 15:08 Matthew Fortune
2016-04-15 22:25 ` Alan Modra
2016-04-18  9:44   ` Matthew Fortune
2016-04-15 23:13 ` Nathaniel Smith
2016-04-15 23:17   ` Nathaniel Smith [this message]
2016-04-18  9:45     ` Matthew Fortune

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPJVwBn6AxN9vB_G=wmmR+zZCg8Yh5j_=FaxcFNVxmRN4ZmMrQ@mail.gmail.com' \
    --to=njs@pobox.com \
    --cc=Anibal.MonsalveSalazar@imgtec.com \
    --cc=Matthew.Fortune@imgtec.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).