This is the mail archive of the
mailing list for the glibc project.
Re: rseq notes from Cauldron
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 23 Sep 2019 11:34:34 -0400 (EDT)
- Subject: Re: rseq notes from Cauldron
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.efficios.com 73FAC24CC72
- References: <email@example.com>
----- On Sep 23, 2019, at 4:45 AM, Florian Weimer firstname.lastname@example.org 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.
> 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.
> Ideally, we should search for RSEQ_SIG in a collection of binaries.
> This is probably something I should do (hopefully some time in
I target October as time-line to do the changes on my end as well.