This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] i386: Remove PLT0 and use non-lazy PLT if PLT0 is unused
- From: Carlos O'Donell <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 8 May 2017 00:53:14 -0400
- Subject: Re: [PATCH] i386: Remove PLT0 and use non-lazy PLT if PLT0 is unused
- Authentication-results: sourceware.org; auth=none
- References: <20170502203156.GA11102@intel.com> <20170504163120.GA19140@intel.com> <20170506151138.GA4151@intel.com> <ca6f1026-e6ab-b82a-92e0-5cc90d1b133f@redhat.com> <CAMe9rOorjioRY9t49f5hDnJ0Pr9vhDeDrZMBM=nOHn3rJgJq1A@mail.gmail.com>
On 05/07/2017 01:00 PM, H.J. Lu wrote:
> On Sat, May 6, 2017 at 11:55 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 05/06/2017 05:11 PM, H.J. Lu wrote:
>>>
>>> 1. Call external function.
>>> 2. Call internal IFUNC function. The best implementation is selected
>>> for the target processor at run-time.
>>> 3. Act as the canonical function address.
>>
>>
>> Audit support is missing from this list. Audit support needs a PLT stub
>> which calls the audit trampoline with some sort of function index or
>> address.
>
> This behavior disables LD_AUDIT support with -z now, in addition to
>
> export LD_BIND_NOW=1
>
> or compiling with -fno-plt. Also should LD_AUDIT work on external
> calls inside shared objects linked with -z now?
Yes IMO, LD_AUDIT + -z now should force the GOT entries to remain forever
resolved to the stub PLT entry in a read-only mapping. This however means
keeping around the PLT entries, which is what you're trying to remove, but
shouldn't without an additional optimization flag.
>> I'm concerned that -z now in recent binutils (even without this patch)
>> removes audit support, when before, audit support was not impacted by -z now
>> (I think, I'm not sure on this point).
>>
>> We really must avoid hardening flags which have profound semantic
>> implications on generated binaries because it discourages people from
>> enabling them.
>
> The impacts for removing PLT0 with -z now are
>
> Cons:
>
> 1. LD_AUDIT no longer works.
This is bad. I know of lots of users that are going to be unhappy if we
continue to remove LD_AUDIT support. For now it works in their own applications,
but I'd like to see LD_AUDIT work with -z now.
> Pros:
>
> 1. Make the run-time behavior the same with "export LD_BIND_NOW=1".
Yes, but it's not a strong enough argument.
> 2. Disable LD_AUDIT to further improve security.
LD_LIBRARY_PATH is already just as dangerous, so is LD_PRELOAD.
And secure processes already ignore LD_AUDIT.
> I can add a new "-z audit" option to enable LD_AUDIT as much as
> possible, including
Why does an existing working feature need a new option?
Why not add a "-z noplt" like gcc has "-fnoplt" and make both options work
together to optimize away the lazy call sequence aspects of the binaries?
We could _also_ add a "-z audit" which is just there to force an error
if mixed with "-z noplt"
> --
> extern void foo (void);
>
> void *
> foo_p ()
> {
> foo ();
> return foo;
> }
> --
>
--
Cheers,
Carlos.