On 19 Oct 2020, at 18:05, David Matthews <David.Matthews at prolingua.co.uk> wrote:
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?
Yes, using .data.rel.ro., i.e. relocatable read-only data.
Jess