Re: rseq notes from Cauldron

[Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>]

----- On Dec 20, 2019, at 2:42 PM, Florian Weimer fw@deneb.enyo.de wrote:

> * Mathieu Desnoyers:
> 
>>> rseq.h already says this:
>>> 
>>>         * […] Also needs to be set to NULL by user-space
>>>         * before reclaiming memory that contains the targeted struct rseq_cs.
>>> 
>>> With dlclose, the struct rseq_cs will likely be gone, not just the
>>> code, so I think in practice, it's already necessary to clear rseq_cs
>>> in userspace.  For completeness, the UAPI header should mention that
>>> this applies to the text region described by struct rseq_cs as well.
>>
>> Actually, it only applies to the struct rseq_cs per se. The kernel
>> does not need to access the text region described by struct rseq_cs.
>> It only uses the start_ip and post_commit_offset fields to figure out
>> if it is indeed preempting a rseq critical section. It does not need
>> to access the memory contents at those addresses. So I don't think
>> any change to the UAPI comment is needed.
> 
> But the unmapping and remapping issue for the text segment is a real
> problem.  There is a semantic dependency here.

Oh, you are right. If the text is unmapped and remapped to completely
different code, it would then be incorrect to assume that the meaning
of the addresses in struct rseq_cs is still valid, even if the
struct rseq_cs is still mapped in memory for some odd reason.

Not that this should happen with the envisioned use (e.g. dlclose),
but I should update the UAPI documentation to clarify this. I may
become handy if JIT start generating rseq critical sections.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com