linux-kernel - Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1602745030.10426.1542911744479.JavaMail.zimbra@efficios.com>
Date:   Thu, 22 Nov 2018 13:35:44 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Szabolcs Nagy <Szabolcs.Nagy@....com>
Cc:     Florian Weimer <fweimer@...hat.com>, nd <nd@....com>,
        Rich Felker <dalias@...c.org>, carlos <carlos@...hat.com>,
        Joseph Myers <joseph@...esourcery.com>,
        libc-alpha <libc-alpha@...rceware.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ben Maurer <bmaurer@...com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Will Deacon <Will.Deacon@....com>,
        Dave Watson <davejwatson@...com>, Paul Turner <pjt@...gle.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api <linux-api@...r.kernel.org>
Subject: Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl
 init and thread creation

----- On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy Szabolcs.Nagy@....com wrote:

> On 22/11/18 15:33, Mathieu Desnoyers wrote:
>> ----- On Nov 22, 2018, at 10:21 AM, Florian Weimer fweimer@...hat.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.

Thanks,

Mathieu


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