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: Fri, 31 Jan 2020 11:40:09 -0500	[thread overview]
Message-ID: <20200131164009.GI1663@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAMw0sz+2uW2eUO-hBMzgJq=BO_O5VUMAZ_8mNZ62bphn68J0ew@mail.gmail.com>

On Fri, Jan 31, 2020 at 06:16:19PM +0300, Андрей Аладьев wrote:
> Hello Markus, I want to ask a question about this one:
> 
> > 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.
> 
> I made a light code overview and found that there is already a mapping for
> segments: "loadmap":
> 
> dso->loadmap->segs[i].p_vaddr = ph->p_vaddr;
> dso->loadmap->segs[i].p_memsz = ph->p_memsz;

This is only for FDPIC, which is not used on any platforms you care
about unless you already know what it is. :-)

> We can add here the following line:
> dso->loadmap->segs[i].readonly = ph->p_flags & PF_W;
> 
> Than add "readonly" into "fdpic_loadseg":
> struct fdpic_loadseg {
>   uintptr_t addr, p_vaddr, p_memsz;
>   bool readonly;
> };

No you can't, because this structure is ABI between the loader (kernel
or otherwise) and the program. It's not an internal structure of the
dynamic linker.

Moreover, adding such a thing is not desirable because it adds a
linear-search of an array of load segments to each relocation,
increasing load time of every correct program for the sake of
diagnosing incorrect ones in a friendly manner. This is not a
reasonable tradeoff and it's why I proposed the "hull" approach
(that's O(1) and safe against bogus relocations clobbering memory
outside the range of the library being relocated, but could still
fault with a mix of LOAD maps). The FDPIC approach is only done
because it's essential for being able to share program text on a
system without MMU, not because it's "nice".

Rich

  reply	other threads:[~2020-01-31 16:40 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
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 [this message]
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=20200131164009.GI1663@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).