rseq notes from Cauldron

[Mathieu Desnoyers]

----- On Sep 23, 2019, at 4:45 AM, Florian Weimer fw@deneb.enyo.de wrote:

> Here are my notes from Cauldron.
> 
> We definitely want to eliminate the intermediate states related to
> __rseq_handled and __rseq_handled itself.  This requires an
> early-initialization callback from the dynamic loader to libc.  This
> is something we (as the libc maintainers) need to provide, and it is
> generally useful for other stuff as well (such as setting up
> __libc_multiple_libcs correctly).  I'm not sure if I can work on this
> before October, though.

OK

> We need to disable symbols in pthread_create, so that signal handlers

I think you meant "disable signals".

> on the new thread cannot observe the lack of rseq registration there.
> I think this can be put into the rseq patch.

OK, that's an action item on my end.

> 
> We need a comment somehwere in NPTL about the reliance of the rseq
> area on implicit deregistration.  This is currently not a problem
> because it lives on the stack (as static TLS), and the stack outlives
> the thread.  But if we ever change the TCB allocation, additional
> steps may be required.  It is NOT sufficient to block signals because
> the kernel may write to the rseq area even without signals.  This
> should go into the rseq patch as well.

This adds a hard requirement on using the IE TLS model AFAIU. Another
action item on my end.

> 
> dlclose needs to reset the cs pointer before unmapping code.  I think
> this should be part of the rseq patch.

Yes, action item on my end.

> 
> We need a little bit of documentation for the manual, mentioning the
> new symbol and the public header.  Likewise, this should be part of
> the patch.

Indeed.

> 
> Ideally, we should search for RSEQ_SIG in a collection of binaries.
> This is probably something I should do (hopefully some time in
> October).

OK,

I target October as time-line to do the changes on my end as well.

Thanks,

Mathieu

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