This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] i386: Remove PLT0 and use non-lazy PLT if PLT0 is unused

On 05/06/2017 02:55 PM, Florian Weimer 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.

> 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).

Audit support is currently disabled by `-z now`, since the early relocation
processing means there is no chance to audit through the _dl_runtime_profile
hook. However, it should IMO not have to be this way. LD_AUDIT could cause
RELRO to lock down the GOT entries and have them _always_ go to 
_dl_runtime_profile, but you still need unique PLT entries for this.

Ignoring this missing feature the problem I have is explained below.

> We really must avoid hardening flags which have profound semantic
> implications on generated binaries because it discourages people from
> enabling them.
I agree completely. I think the problem that I see is that binutils changes
like PLT elision cause PLTREL to be removed which requires glibc changes
before any tooling using LD_AUDIT can work properly, and that's a bad
sequence of effects. Worse without a PLT you can't even fix these binaries
down the road if we enable a Full RELRO LD_AUDIT because you'd need to
recompile everything.

Optimizations like removing PLT entries should be just that, optimizations
that aren't turned on by `-z now`. Though how much is really a question of
what we call ABI? Are PLT entries ABI? I would argue they are for developer
tooling and LD_AUDIT purposes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]