mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] Add REL_COPY size change detection
Date: Wed, 26 Feb 2020 17:02:40 -0500	[thread overview]
Message-ID: <20200226220240.GC11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200226201202.GB2769@voyager>

On Wed, Feb 26, 2020 at 09:12:02PM +0100, Markus Wichmann wrote:
> On Wed, Feb 26, 2020 at 12:36:21PM -0500, Rich Felker wrote:
> > In theory copy relocations should have been gone for everyone who
> > switched to PIE, but then the gcc/binutils folks brought them back as
> > an "optimization" (allowing pc-rel access to external symbols). :-(
> >
> 
> Several quotes about optimization come to mind. Especially ones with the
> word "premature" in them.
> 
> I just checked and I saw that there are no copy relocs in my libraries,
> but my binaries are indeed PIEs. Therefore I have to conclude that gcc
> compiles PIE and PIC differently. Weren't they meant to be the same,
> except maybe for the selection of object files during the linker phase?

Libraries inherently can't have copy relocations. Only the main
program can.

> > 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.
> >
> 
> If the application did import sym->st_size bytes, it probably wanted to
> do something with them.

Not really. For example:

extern char *strings[];
extern size_t nstrings;

This type of thing was common with historical mistakes like
sys_errlist, the equivalent for signals, etc., where the application
either had an out-of-band way of knowing the runtime-provided size, or
it could just assume all indices it got from the library were
in-bounds to access the array. It went out of fashion entirely because
of copy relocations breaking it.

> > Missing , after name, and the indent is weird (2 extra levels). I'd
> > either align (spaces) with the opening paren or use just one indent
> > level, and fewer lines.
> 
> The missing comma is weird. Must have gone missing as I was cutting that
> line down to size (originally, I had this as one line, but then it was
> around 200 columns long, and I thought that was a bit excessive). So
> then I tried to stay below 80 and you see the result before you.
> 
> The indent was just vim's default setting. Usually this suits me, but
> usually I have shiftwidth=4 and expandtab. For musl, it's sw=8 and noet.
> 
> > Semantically, st_size is size_t not ulong, so I'd probably lean
> > towards a cast to (size_t) here with %zu.
> 
> Isn't on Linux size_t always a ulong? I will admit I only went for ulong
> because it's easier to write the cast.

Yes, but the ldso code doesn't use that assumption, or at least it's
not intended to. It's used to some extent elsewhere in the syscall
glue framework.

Rich

      reply	other threads:[~2020-02-26 22:02 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
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 [this message]

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=20200226220240.GC11469@brightrain.aerifal.cx \
    --to=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).