This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Is it a GNU Tools failure that PIE use ET_DYN and can't be distinguished from libraries?
- From: Florian Weimer <fweimer at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 16 Mar 2015 18:04:54 +0100
- Subject: Re: Is it a GNU Tools failure that PIE use ET_DYN and can't be distinguished from libraries?
- Authentication-results: sourceware.org; auth=none
- References: <55070AEC dot 5080107 at redhat dot com>
On 03/16/2015 05:55 PM, Carlos O'Donell wrote:
> While looking at recent ABI comparison failures I noticed that
> some internal Red Hat tooling was looking at PIEs and treating
> their exported dynamic symbols as fixed ABI/API that must not
> change.
That's a conservative first approximation, but it's independent of
ET_DYN/ETEXEC.
> The truth is that from the tooling perspective you can't tell the
> difference between a PIE and an ET_DYN, except that you might guess
> PIE if you see PT_INTERP (and you'd be wrong for libc.so and
> ld.so)
I don't think this matters.
> Is it a failing of the tooling that we didn't provide a way for
> tools to determine PIE vs. DSO?
No, it's conceivable that we ship code where the executable provides a
public ABI. From my memory, candidates are PostgreSQL and Apache httpd.
For other distributions, this could apply to the Perl, Python, Lua
interpreters.
Manual inspection is needed to tell if symbols exported from an
executable form a public ABI or not. If the tooling ignores exported
symbols just because the object is ET_EXEC, it is broken and risks
missing relevant ABI changes.
--
Florian Weimer / Red Hat Product Security