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] Static linking is broken after creation of DT_TEXTREL segment
Date: Thu, 30 Jan 2020 23:24:31 -0500	[thread overview]
Message-ID: <20200131042431.GC1663@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200130170249.GK2020@voyager>

On Thu, Jan 30, 2020 at 06:02:49PM +0100, Markus Wichmann wrote:
> > > Iterate over the apps PHDRs and remove write protection from all RO
> > segments?
> >
> > So libc knows that file is mapped as readonly and should not try to write
> > into readonly pointers.
> 
> Almost all relocations point to writable memory. For obvious reasons. So
> musl doesn't check this.
> 
> The issue is more complicated, because the app can have an unbounded
> number of PT_LOAD segments with the PF_W flag absent. So checking the
> relocations would require the dynlinker to first iterate over all PHDRs
> to check for the unlikely case that textrels are present. Only because
> they might be.

Right. Not specific to textrels, I actually do want to make ldso track
the hull of writable address range for each dso and validate
relocations against it before attempting to apply them. This would
allow error reporting without significant runtime cost (vs iterating
LOAD segments) and would be a first step towards possibly making ldd
of untrusted binaries safe (though that requires a lot more).

> > Libc can do the following:
> >
> > 1. Ignore impossible relocations.
> > 2. Add a warning to stderr and still ignore impossible relocations.
> > 3. do abort, user will receive SIGABRT and understand that he uses libc in
> > a wrong way.
> >
> > Segfault is not an acceptable answer.
> >
> 
> Have I got news for you. Unlike glibc, musl does not indicate
> irrecoverable state with a litany into stderr, but usually by calling
> a_crash(), which will terminate the process by executing an illegal
> instruction. This typically results in SIGILL being delivered, but on
> some archs it is still a segfault.

This is true, but that's after the program has started execution. The
dynamic linker does report errors when it's practical to do so, either
to stderr before execution or via dlerror at runtime. So detecting and
reporting this would not be unprecedented.

> Also, there is at least one place in the dynlinker where, as I recall,
> mmap() is being called directly, but rather than check for errors in the
> return value, the value is just used, because all error returns cause
> segfaults.

I believe this was fixed in 77846800722914eeba170505c2e7f89e12a6beff.

> And then there was the case of PowerPC's original ABI, now called the
> BSS-PLT ABI, which expects the dynlinker to fill out the PLT at runtime,
> which musl doesn't do. Trying to run a BSS-PLT binary with musl will
> therefore also very quickly segfault.

I thought it would produce an error for unsupported relocation type,
but maybe not if the same relocation numbers were reused. This should
probably be improved.

> Anyway, option 1 would leave the relocations unprocessed, typically
> leading to invalid code references down the line, and therefore another
> segfault.

Right. This is really bad and not on the table.

> Option 2 is the same but wordier.

Likewise this makes no sense at all.

> Option 3 has a chance to be
> subverted (user could block or ignore SIGABRT before executing the main
> binary. With SIGSEGV or SIGILL, the user can block or ignore those, but
> then the kernel will just kill the process outright if those conditions
> arrise).

Assuming this is at startup, that's not a possibility; no application
code has run yet. But ldso already has a fatal error mechanism; it
doesn't need to treat this one differently.

For runtime (dlopen), aborting is not an option. Syntactically valid
files which cannot be loaded for semantic reasons should be an error
reported by dlerror. (musl makes no claim to handle syntactically
invalid files safely; doing so is rather difficult and would require
some intense hardening work, and is of little use except for ldd since
otherwise a malicious file could just have malicious code in its
ctors...)

The right action here in the long term is probably reporting
unsupported files rather than crashing. But it's a fairly minor issue
and depends on some infrastructure that's not yet done for tracking
address ranges.

Rich

  reply	other threads:[~2020-01-31  4:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 18:41 Андрей Аладьев
2020-01-29 19:19 ` Markus Wichmann
2020-01-29 19:38   ` Markus Wichmann
2020-01-29 20:48     ` Rich Felker
2020-01-29 20:08   ` Андрей Аладьев
2020-01-30 17:02     ` Markus Wichmann
2020-01-31  4:24       ` Rich Felker [this message]
2020-01-31 14:47         ` Markus Wichmann
2020-01-31 16:35           ` Rich Felker
2020-01-31 15:16       ` Андрей Аладьев
2020-01-31 16:40         ` Rich Felker
2020-01-31 17:51           ` Андрей Аладьев
2020-01-31 18:01             ` Rich Felker
2020-01-31 19:11               ` Андрей Аладьев
2020-02-03  3:10       ` Rich Felker
2020-02-03  4:05         ` Rich Felker
2020-02-03  4:32         ` Markus Wichmann
2020-02-03  4:40           ` Rich Felker
2020-01-29 20:53 ` Rich Felker
2020-01-29 21:10   ` Szabolcs Nagy
2020-01-29 21:35     ` Андрей Аладьев
2020-01-29 21:46       ` Rich Felker
2020-01-29 23:10         ` Андрей Аладьев
2020-01-29 23:20       ` Szabolcs Nagy
2020-01-29 21:14   ` Андрей Аладьев
2020-01-29 21:43     ` 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=20200131042431.GC1663@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).