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  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 21:15:21 +0000 (UTC)
From:   Mathieu Desnoyers <>
To:     Will Deacon <>
Cc:     Peter Zijlstra <>,
        Andi Kleen <>,
        "Paul E. McKenney" <>,
        Boqun Feng <>,
        Andy Lutomirski <>,
        Dave Watson <>,
        linux-kernel <>,
        linux-api <>,
        Paul Turner <>,
        Andrew Morton <>,
        Russell King <>,
        Thomas Gleixner <>,
        Ingo Molnar <>,
        "H. Peter Anvin" <>, Andrew Hunter <>,
        Chris Lameter <>, Ben Maurer <>,
        rostedt <>,
        Josh Triplett <>,
        Linus Torvalds <>,
        Catalin Marinas <>,
        Michael Kerrisk <>
Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op

----- On Nov 22, 2017, at 2:37 PM, Will Deacon wrote:

> On Wed, Nov 22, 2017 at 08:32:19PM +0100, Peter Zijlstra wrote:
>> On Tue, Nov 21, 2017 at 10:05:08PM +0000, Mathieu Desnoyers wrote:
>> > Other than that, I have not received any concrete alternative proposal to
>> > properly handle single-stepping.
>> That's not entirely true; amluto did have an alternative in Prague: do
>> full machine level instruction emulation till the end of the rseq when
>> it gets 'preempted too often'.
>> Yes, implementing that will be an absolute royal pain. But it does
>> remove the whole duplicate/dual program asm/bytecode thing and avoids
>> the syscall entirely.
>> And we don't need to do a full x86_64/arch-of-choice emulator for this
>> either; just as cpu_opv is fairly limited too. We can do a subset that
>> allows dealing with the known sequences and go from there -- it can
>> always fall back to not emulating and reverting to the pure rseq with
>> debug/fwd progress 'issues'.
>> 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.



> Will

Mathieu Desnoyers
EfficiOS Inc.

Powered by blists - more mailing lists