This is the mail archive of the
mailing list for the glibc project.
Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, Florian Weimer <fweimer at redhat dot com>, nd <nd at arm dot com>, carlos <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, libc-alpha <libc-alpha at sourceware dot org>, Thomas Gleixner <tglx at linutronix dot de>, Ben Maurer <bmaurer at fb dot com>, Peter Zijlstra <peterz at infradead dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Boqun Feng <boqun dot feng at gmail dot com>, Will Deacon <Will dot Deacon at arm dot com>, Dave Watson <davejwatson at fb dot com>, Paul Turner <pjt at google dot com>, linux-kernel <linux-kernel at vger dot kernel dot org>, linux-api <linux-api at vger dot kernel dot org>
- Date: Thu, 22 Nov 2018 14:36:25 -0500 (EST)
- Subject: Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.efficios.com 92DE37B119
- References: <firstname.lastname@example.org> <email@example.com> <20181122151710.GF23599@brightrain.aerifal.cx> <firstname.lastname@example.org> <1306224240.10055.1542900799576.JavaMail.email@example.com> <firstname.lastname@example.org> <1602745030.10426.1542911744479.JavaMail.email@example.com> <20181122190143.GI23599@brightrain.aerifal.cx>
----- On Nov 22, 2018, at 2:01 PM, Rich Felker firstname.lastname@example.org wrote:
> On Thu, Nov 22, 2018 at 01:35:44PM -0500, Mathieu Desnoyers wrote:
>> ----- On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy Szabolcs.Nagy@arm.com wrote:
>> > On 22/11/18 15:33, Mathieu Desnoyers wrote:
>> >> ----- On Nov 22, 2018, at 10:21 AM, Florian Weimer email@example.com wrote:
>> >>> Right, but in case of user-supplied stacks, we actually free TLS memory
>> >>> at this point, so signals need to be blocked because the TCB is
>> >>> (partially) gone after that.
>> >> Unfortuntately, disabling signals is not enough.
>> >> With rseq registered, the kernel accesses the rseq TLS area when returning to
>> >> user-space after _preemption_ of user-space, which can be triggered at any
>> >> point by an interrupt or a fault, even if signals are blocked.
>> >> So if there are cases where the TLS memory is freed while the thread is still
>> >> running, we _need_ to explicitly unregister rseq beforehand.
>> > i think the man page should point this out.
>> Yes, I should add this to the proposed rseq(2) man page.
>> > the memory of a registered rseq object must not be freed
>> > before thread exit. (either unregister it or free later)
>> > and ideally also point out that c language thread storage
>> > duration does not provide this guarantee: it may be freed
>> > by the implementation before thread exit (which is currently
>> > not observable, but with the rseq syscall it is).
>> How about the following wording ?
>> Memory of a registered rseq object must not be freed before the
>> thread exits. Reclaim of rseq object's memory must only be
>> done after either an explicit rseq unregistration is performed
>> or after the thread exit. Keep in mind that the implementation
>> of the Thread-Local Storage (C language __thread) lifetime does
>> not guarantee existence of the TLS area up until the thread exits.
> This is all really ugly for application/library code to have to deal
> with. Maybe if the man page is considered as documenting the syscall
> only, and not something you can use, it's okay,
This is indeed for the rseq(2) manpage targeting the man-pages project,
which documents system calls.
> but "until the thread
> exits" is not well-defined in the sense you want it here. It's more
> like "until the kernel task for the thread exits", and the whole point
> is that there is some interval in time between the abstract thread
> exit and the kernel task exit that is not observable without rseq but
> is observable if the rseq is wrongly left installed.
It's important to clear a possible misunderstanding here: from the
point where the thread issues the "exit" system call, the kernel won't
touch the registered rseq TLS area anymore.
So the point where the thread exits is actually well defined, even from
a user-space perspective.
The problematic scenario arises when glibc frees the TLS memory
before invoking exit() when the thread terminates. In this kind of
scenario, we need to explicitly invoke rseq unregister before TLS