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
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
