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:   Mon, 16 Apr 2018 15:21:19 -0400 (EDT)
From:   Mathieu Desnoyers <>
To:     Linus Torvalds <>
Cc:     Andy Lutomirski <>,
        Peter Zijlstra <>,
        "Paul E. McKenney" <>,
        Boqun Feng <>,
        Dave Watson <>,
        linux-kernel <>,
        linux-api <>,
        Paul Turner <>,
        Andrew Morton <>,
        Russell King <>,
        Thomas Gleixner <>,
        Ingo Molnar <>,
        "H. Peter Anvin" <>, Andrew Hunter <>,
        Andi Kleen <>, Chris Lameter <>,
        Ben Maurer <>, rostedt <>,
        Josh Triplett <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Michael Kerrisk <>
Subject: Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call

----- On Apr 16, 2018, at 2:39 PM, Linus Torvalds wrote:

> On Mon, Apr 16, 2018 at 11:35 AM, Mathieu Desnoyers
> <> wrote:
>> Specifically for single-stepping, the __rseq_table section introduced
>> at user-level will allow newer debuggers and tools which do line and
>> instruction-level single-stepping to skip over rseq critical sections.
>> However, this breaks existing debuggers and tools.
> I really don't think single-stepping is a valid argument.
> Even if the cpu_opv() allows you to "single step", you're not actually
> single stepping the same thing that you're using. So you are literally
> debugging something else than the real code.
> At that point, you don't need "cpu_opv()", you need to just load
> /dev/urandom in a buffer, and single-step that. Ta-daa! No new kernel
> functionality needed.
> So if the main argument for cpu_opv is single-stepping, then just rip
> it out. It's not useful.

No, single-stepping is not the only use-case. Accessing remote cpu
data is another use-case fulfilled by cpu_opv, which I think is more

> Anybody who cares deeply about single-stepping shouldn't be using
> optimistic algorithms, and they shouldn't be doing multi-threaded
> stuff either. They won't be able to use things like transactional
> memory either.
> You can't single-step into the kernel to see what the kernel does
> either when you're debugging something.
> News at 11: "single stepping isn't always viable".

I don't mind if people cannot stop the program with a debugger and
observe the state of registers manually at each step though a rseq
critical section.

I do mind breaking existing tools that rely on single-stepping
approaches to automatically analyze program behavior [1,2].
Introducing a rseq critical section into a library (e.g. glibc
memory allocator) would cause existing programs being analyzed
with existing tools to hang.

And I try very hard to avoid being told I'm the one breaking
user-space. ;-)




Mathieu Desnoyers
EfficiOS Inc.

Powered by blists - more mailing lists