linux-kernel - Re: [RFC PATCH glibc 09/13] glibc: Perform rseq(2) registration at C startup and thread creation (v13)

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] [day] [month] [year] [list]

Message-ID: <1968185366.4418.1578429840460.JavaMail.zimbra@efficios.com>
Date:   Tue, 7 Jan 2020 15:44:00 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     carlos <carlos@...hat.com>, Joseph Myers <joseph@...esourcery.com>,
        Szabolcs Nagy <szabolcs.nagy@....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>,
        Rich Felker <dalias@...c.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api <linux-api@...r.kernel.org>
Subject: Re: [RFC PATCH glibc 09/13] glibc: Perform rseq(2) registration at
 C startup and thread creation (v13)



----- On Jan 7, 2020, at 7:23 AM, Florian Weimer fweimer@...hat.com wrote:

> * Mathieu Desnoyers:
> 
>> Register rseq(2) TLS for each thread (including main), and unregister
>> for each thread (excluding main). "rseq" stands for Restartable
>> Sequences.
>>
>> See the rseq(2) man page proposed here:
>>   https://lkml.org/lkml/2018/9/19/647
>>
>> This patch is based on glibc-2.30. The rseq(2) system call was merged
>> into Linux 4.18.
> 
> This patch needs to be updated for some be/le abilist splits.
> Big-endian ABI lists for arm, microblaze, sh, appear to be missing.

done.

> This is something that can be checked with build-many-glibcs.py.

OK.

> 
>> diff --git a/manual/threads.texi b/manual/threads.texi
>> index 0858ef8f92..059f781120 100644
>> --- a/manual/threads.texi
>> +++ b/manual/threads.texi
>> @@ -881,3 +881,20 @@ Behaves like @code{pthread_timedjoin_np} except that the
>> absolute time in
>>  @c pthread_spin_unlock
>>  @c pthread_testcancel
>>  @c pthread_yield
>> +
>> +@...e Restartable Sequences
>> +@...tion Restartable Sequences
>> +@...dex rseq
>> +
>> +This section describes the @glibcadj{} Restartable Sequences integration.
>> +
>> +The @glibcadj{} implements a __rseq_abi TLS symbol to interact with the
>   @Theglibc{}                  @code{__rseq_abi}
> 
> 
>> +Restartable Sequences system call (Linux-specific). The layout of this
>> +structure is defined by the Linux kernel rseq.h UAPI. Registration of each
>> +thread's __rseq_abi is performed by @glibcadj{} at libc initialization and
>                                       @theglibc{}
>           @code{__rseq_abi}
>> +pthread creation.
> 
>> +Each supported architecture provide a RSEQ_SIG signature in sys/rseq.h. That
>                                         @code{RSEQ_SIG}       @file{sys/rseq.h}
> 
>> +signature is expected to be present in the code before each Restartable
>> +Sequences abort handler. Failure to provide the expected signature may
>> +terminate the process with a Segmentation fault.
> 
> 
> Two spaces at the end of setences, please.

All above done.

> 
> The manual should use @deftypevar to create an index entry etc. for
> __rseq_abi.  See argp_program_version for an example of how to do this.

OK. I've added __rseq_abi as a variable and RSEQ_SIG as a macro.

> 
> I think current policy is to have documentation for at least the minimum
> functionality in the manual.  I understand that it makes it a lot of
> work to write patches which add system call wrappers.

Makes sense.

Thanks!

Mathieu

> 
> Thanks,
> Florian

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