Re: [musl] Static linking is broken after creation of DT_TEXTREL segment

[Markus Wichmann <nullplan@gmx.net>]

On Wed, Jan 29, 2020 at 09:41:46PM +0300, Андрей Аладьев wrote:
> gcc main.c /usr/lib/libgmp.a -o main && ./main

Ooh boy, why would you do this? When there's a perfectly good -lgmp just
waiting for you.

> warning: creating a DT_TEXTREL in object

The warning is justified, you usually do not want to do this. With a
TEXTREL, the code has to be mapped as writable, so now programming
errors and exploits can change the executable code.

> We can see that "laddr" provided pointer to "dso->base + rel[0]", than
> switch tried to override it's value and segfault appeared. Pointer is
> wrong, most likely readonly.
>

Pointer is correct, but memory should have been mapped writable. More on
this in a bit.

> You can replace "gcc" with "clang" and everything will be the same. Updated
> binutils to most recent version 2.33.1 and rebuilt toolchain - nothing
> changed. Pointer is still invalid and SEGV_ACCERR appears.
>

Of course. The issue is a relocation inside a read-only segment.
Binutils and compiler are not malfunctioning.

> So I think that bug is inside musl itself. Glibc container is the same
> situation works fine. I see no way to create a workaround for this issue.

Well, the remedy is obvious: Get rid of the TEXTREL. It is usually
caused by bad assembly source code, and fixable with only minor
knowledge of the details. Consult the search engine of your least
distrust for more information on this.

Regarding the actual problem though, the problem here is that DT_TEXTREL
is handled only in map_library(), so it is not handled for kernel mapped
DSOs. Which isn't a problem for libc or the VDSO, but the app itself
might be TEXTREL (and is, in this case), and that isn't handled. How,
though? Iterate over the apps PHDRs and remove write protection from all
RO segments?

And one more question: Since musl resolves all relocations immediately,
couldn't we write-protect TEXTREL modules after relocating them?
Provided no unresolved relocations remain, of course.

Ciao,
Markus