linux-kernel - Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable sequences system call (v12)

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: <729438855.35910.1513356742518.JavaMail.zimbra@efficios.com>
Date:   Fri, 15 Dec 2017 16:52:22 +0000 (UTC)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Chris Lameter <cl@...ux.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Andy Lutomirski <luto@...capital.net>,
        Dave Watson <davejwatson@...com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api <linux-api@...r.kernel.org>,
        Paul Turner <pjt@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Russell King <linux@....linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Andrew Hunter <ahh@...gle.com>,
        Andi Kleen <andi@...stfloor.org>, Ben Maurer <bmaurer@...com>,
        rostedt <rostedt@...dmis.org>,
        Josh Triplett <josh@...htriplett.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable
 sequences system call (v12)

----- On Dec 15, 2017, at 10:05 AM, Chris Lameter cl@...ux.com wrote:

> On Thu, 14 Dec 2017, Peter Zijlstra wrote:
> 
>> > But my company has extensive user space code that maintains a lot of
>> > counters and does other tricks to get full performance out of the
>> > hardware. Such a mechanism would also be good from user space. Why keep
>> > the good stuff only inside the kernel?
>>
>> Mathieu's proposal is for userspace, _only_ userspace.
> 
> But what we were talking about are instructions that work effectively in
> kernel space whose efficiency restartable sequences could bring to user
> space.

It can be worthwhile to recap my understanding of this thread so far:

AFAIU, Chris' proposal is to use the "gs" segment selector as instruction
prefix on x86 rather than explicitly loading CPU number and calculating
offsets.

This can turn sequences of rseq operations like this cmpxchg:

Registers:

  R1: return value
  R2: expected value
  R3: new value
  R4: cpu_id

rseq cmpxchg:

  load TLS::cpu_id_start into R4
  calculate offset of v
  fs:mov (store rseq descriptor address into TLS::rseq_cs)
  compare R4 against TLS::cpu_id
  jne abort
  mov (load v into R1)
  compare R1 against R2
  jne cmpfail
  mov (store R3 into *v)

into:

  fs:mov (store rseq descriptor address into TLS::rseq_cs)
  gs:mov (load *v+off into R1)
  compare R1 against R2
  jne cmpfail
  gs:mov (store R3 into *v+off)

My first concern with this approach is the lack of flexibility of the segment
selector method wrt variety of schemes user-space has to deal with for memory
allocation. In the kernel, this is achieved by ensuring that all per-cpu data
layout is segment-selector-prefix friendly.

Another aspect that worries me is applications using the gs segment selector
for other purposes. Suddenly reserving the gs segment selector for use by a
library like glibc may lead to incompatibilities with applications already
using it.

Thanks,

Mathieu

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