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:   Wed, 3 Feb 2021 10:10:35 -0800
From:   Linus Torvalds <>
To:     Gabriel Krisman Bertazi <>
Cc:     Kyle Huey <>, Andy Lutomirski <>,
        Thomas Gleixner <>,
        Andy Lutomirski <>,
        open list <>,
        "Robert O'Callahan" <>
Subject: Re: [PATCH] entry: Fix missed trap after single-step on system call return

On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
<> wrote:
> Does the patch below follows your suggestion?  I'm setting the
> SYSCALL_WORK shadowing TIF_SINGLESTEP every time, instead of only when
> the child is inside a system call.  Is this acceptable?

Looks sane to me.

My main worry would be about "what about the next system call"? It's
not what Kyle's case cares about, but let me just give an example:

 - task A traces task B, and starts single-stepping. Task B was *not*
in a system call at this point.

 - task B happily executes one instruction at a time, takes a TF
fault, everything is good

 - task B now does a system call. That will disable single-stepping
while in the kernel

 - task B returns from the system call. TF will be set in eflags, but
the first instruction *after* the system call will execute unless we
go through the system call exit path

So I think the tracer basically misses one instruction when single-stepping.

I think your patch works for this case (because the SYSCALL_EXIT_TRAP
flag stays set until single-stepping is done), so I think it's all
good. But can you verify, just to allay my worry?


Powered by blists - more mailing lists