linux-kernel - Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op vector

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]

Date:   Thu, 23 Nov 2017 23:51:27 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
cc:     Will Deacon <will.deacon@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andi Kleen <andi@...stfloor.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>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Andrew Hunter <ahh@...gle.com>,
        Chris Lameter <cl@...ux.com>, Ben Maurer <bmaurer@...com>,
        rostedt <rostedt@...dmis.org>,
        Josh Triplett <josh@...htriplett.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op
 vector

On Thu, 23 Nov 2017, Mathieu Desnoyers wrote:
> ----- On Nov 22, 2017, at 2:37 PM, Will Deacon will.deacon@....com wrote:
> > On Wed, Nov 22, 2017 at 08:32:19PM +0100, Peter Zijlstra wrote:
> >>
> >> So what exactly is the problem of leaving out the whole cpu_opv thing
> >> for now? Pure rseq is usable -- albeit a bit cumbersome without
> >> additional debugger support.
> > 
> > Drive-by "ack" to that. I'd really like a working rseq implementation in
> > mainline, but I don't much care for another interpreter.
> 
> Considering the arm 64 use-case of reading PMU counters from user-space
> using rseq to prevent migration, I understand that you're lucky enough to
> already have a system call at your disposal that can perform the slow-path
> in case of single-stepping.
> 
> So yes, your particular case is already covered, but unfortunately that's
> not the same situation for other use-cases that have been expressed.

If we have users of rseq which can do without the other muck, then what's
the reason not to support it?

The sysops thing can be sorted out on top and the use cases which need both
will have to test for both syscalls being available anyway.

Tanks,

	tglx