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

[Markus Wichmann <nullplan@gmx.net>]

On Thu, Jan 30, 2020 at 11:24:31PM -0500, Rich Felker wrote:
> > 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.
>

No, that wasn't what I meant. I looked it up: I meant the one in
static_init_tls(). Note that this was no criticism, I fully agree that
crashing is acceptable in case of a rare failure. As long as it happens
repeatably and only during early startup.

> > 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.
>

Honestly, I went on memory on this. I thought I remembered an FAQ or
wiki entry that said that without secure PLT, you would get crashes. I
never tried it myself.

OK, so the ABI says that the PLT relocations are of type R_PPC_JMP_SLOT.
Which arch/powerpc/reloc.h defines as REL_PLT. Therefore the dynlinker
will see these relocations and perform a generic PLT relocation when the
esoteric BSS-PLT relocation would be called for.

I am using this ABI document here: https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf

It appears the type R_PPC_JMP_SLOT did get reused for the secure PLT
option. Therefore our only way to detect BSS-PLT binaries and quit with
a nice error message is to detect the absence of the secure PLT option
in the dynamic section.

Coincidentally, we might give the OP a nice error message as well if we
checked the application's dynamic section and found a DT_TEXTREL tag.

> Assuming this is at startup, that's not a possibility; no application
> code has run yet.

Unfortunately, signal mask and ignore dispositions are inherited across
execve(). A tool that ignores or blocks specific signals before execing
the rest of its command line is therefore possible. I seem to remember
such a tool, but cannot remember its name. A cursory search on the
Internet failed to turn up anything.

Ciao,
Markus