Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 31 Jan 2020 11:40:09 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Static linking is broken after creation of DT_TEXTREL
 segment

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

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.