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 19:38:31 +0100 [thread overview]
Message-ID: <87a7556vo8.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20200226173621.GA11469@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 26 Feb 2020 12:36:21 -0500")
* 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.
next prev parent reply other threads:[~2020-02-26 18:40 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 [this message]
2020-02-26 19:00 ` Rich Felker
2020-02-26 19:53 ` Florian Weimer
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=87a7556vo8.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).