This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: How to detect symbol interposition?
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, libc-help <libc-help at sourceware dot org>
- Date: Thu, 30 Jun 2016 14:21:39 +0200
- Subject: Re: How to detect symbol interposition?
- Authentication-results: sourceware.org; auth=none
- References: <82beb432-5022-3b05-0877-8b9883cb004c at redhat dot com> <39ea32b7-e066-4122-8d87-580ad8ba816e at redhat dot com>
On 06/28/2016 07:00 PM, Carlos O'Donell wrote:
On 06/28/2016 10:12 AM, Florian Weimer wrote:
I need a way to detect symbol interposition from within libc.
I assume you mean you will be writing code that lives in libc and needs
to determine that ld.so has interposed a libc symbol with a symbol from
another library?
Yes.
It seems that this is not directly distinguishable from interposition
based on addresses alone:
[snip]
If I have a hidden alias of malloc within libc (say, __libc_malloc),
so that I can get the original address, it will be not equal to
malloc because malloc in the entire process will point to the PLT
stub. The PLT stub will call malloc, of course, but you cannot tell
this from its address.
And this changes depending on the architecture details.
Are their architectures where the interposition is made explicit and
shows up in .dynsym?
The only solution that I know of is to use the LD_AUDIT mechanisms to
catch the PLT resolution and observe the final address of the resolution.
The logic has to go into libc.so proper, so LD_AUDIT is not an option.
Unless there are architectures where the static linker constructs PLT
stubs with special relocations (RTLD_NEXT-style) and then interposes the
PLT stub via .dynsym, surely ld.so has access to this information, at
least at a conceptual level?
Thanks,
Florian