On 19 Oct 2020, at 18:05, David Matthews <[email protected]> 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 _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
