On 19/10/2020 09:19, Stefan O'Rear wrote:
AFAIK, strictly speaking, executability is not relevant here. The Linux manpage documents DT_TEXTREL as "Absence of this entry indicates that no relocation entries should apply to a nonwritable segment" and musl is crashing because it maps the text segment with r-x permissions, and then attempts to write to it while processing relocations.
A related issue is that musl only implements the relocation types that are useful in data sections, i.e. "write absolute address to a word-sized adequately aligned field".
I think you're right about the issue being relocations in any read-only section, not just the code as I'd imagined.
I've been doing some tests with the byte-code interpreted version. Currently the interpreted code is put in the text section but there's no need for that; it really should be put in the read-only data area along with all the other immutable data. However, even then the linker on OpenBSD complains about relocations in the read-only data area and I am guessing that this has to do as much with the rest of the data as with the byte code. Writing everything to a read-write area solves the problem.
This seems bizarre. What it means is that it is actually necessary weaken security by making immutable data writeable in order to allow absolute addresses. I would have expected the loader to deal with the relocations in the read-only data area and then remove write access from the pages. Is there any way round this?
Supporting PIE on 32-bit x86 would be harder. Would it be reasonable to have a configure test which automatically sets -no-pie if the linker supports it, and/or if a test program with a text relocation cannot be run?
That would certainly be a good idea.
Regards, David