linux-kernel - Desired behavior from a gdb perspective for single-step (x86)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <fff293d0-1bf8-42de-adea-a7e7ee559777@zytor.com>
Date: Wed, 21 May 2025 15:06:47 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: gdb@...rceware.org
Cc: Andrew Burgess <aburgess@...hat.com>, Xin Li <xin3.li@...el.com>,
        Xin Li <xin@...or.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Desired behavior from a gdb perspective for single-step (x86)

Hi,

With FRED x86 has the ability for the single step flag (TF) to trigger
immediately after a return to user space. By default, we do that that
when we return to user space after entering the kernel via a system call
instruction of some kind (syscall, sysenter, INT) so that from a user
space perspective, the system call appears as one single instruction (as
opposed to skipping over the following instruction, which is the
behavior with IRET.)

We did discover that to make it work properly in the case of the TF
being used without a debugger attached, we need to clear the
immediate-trap flag in the sigreturn handler, to avoid an infinite loop
where SIGTRAP is taken over and over again.

Our current thinking is that we will clear the trap-immediately bit in
sigreturn if TF is *not* set before sigreturn is called, and Xin
preparing a kernel patch to do that to fix the mentioned infinite loop.

What isn't entirely clear to me is how ptrace should play into all of
this, and specifically, what does gdb (or another debugger) *WANT* the
behavior to be. We have the opportunity to make it "better" than the IDT
behavior, so it would be good to hear what specific semantics you would
prefer to have.

Thanks!

	-hpa