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
next prev parent 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).