mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] Add REL_COPY size change detection
Date: Wed, 26 Feb 2020 20:53:03 +0100	[thread overview]
Message-ID: <874kvd6s80.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20200226190042.GB11469@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 26 Feb 2020 14:00:42 -0500")

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

  reply	other threads:[~2020-02-26 19:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26  5:24 Markus Wichmann
2020-02-26 17:36 ` Rich Felker
2020-02-26 18:38   ` Florian Weimer
2020-02-26 19:00     ` Rich Felker
2020-02-26 19:53       ` Florian Weimer [this message]
2020-02-26 22:48         ` Rich Felker
2020-02-27  5:00           ` Fangrui Song
2020-04-17 10:58           ` Florian Weimer
2020-02-26 20:12   ` Markus Wichmann
2020-02-26 22:02     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kvd6s80.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).