[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874kvd6s80.fsf@mid.deneb.enyo.de>
Date: Wed, 26 Feb 2020 20:53:03 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] Add REL_COPY size change detection
* Rich Felker:
> On Wed, Feb 26, 2020 at 07:38:31PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > At the very least I think we ought to catch and error on the case
>> > where def.sym->st_size>sym->st_size, since we can't honor it and
>> > failure to honor it can produce silent memory corruption. I'm less
>> > sure about what to do if def.sym->st_size<sym->st-size; this case
>> > seems safe and might be desirable not to break (I vaguely recall an
>> > intent that it be ok), but if you think there are reasons it's
>> > dangerous I'm ok with disallowing it too. I'm having a hard time now
>> > thinking of a reason it would really help to support that, anyway.
>>
>> Unfortunately the Mozilla NSS people disagree that size mismatches for
>> global symbols are an ABI break. I don't know if this is relevant in
>> the musl context, but it means that for glibc, we probably can't make
>> it a hard error.
>>
>> I want to have better diagnostics for this in glibc, but the current
>> warning (which is poorly worded at that) is in the
>> architecture-specific code, and I got side-tracked when I tried to
>> clean this up the last time.
>
> Thanks for the feedback. Do you have a source where we could read more
> about this? What non-broken behavior do they expect to get when sizes
> don't match?
There's an NSS bug report:
<https://bugzilla.mozilla.org/show_bug.cgi?id=1201900>
It seems that the NSS situation is better than what I remembered.
> As an aside, I think we should be encouraging distros that are using
> PIE to get rid of copy relocations by passing whatever options are
> needed (or building gcc with whatever options are needed) to avoid
> emitting them in PIE. IIRC I looked this up once but I can't remember
> what I found.
If I recall correctly, the optimization was a factor when rolling out
PIE-by-default in Fedora. I do not know if we can revert it without
switching back to fixed-address builds.
Even if we did that, the ABI incompatibility will still be there.
There is also a similar truncation issue for TLS variables, I think.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
