From: Jinjie Ruan <ruanjinjie@huawei.com>
To: Kees Cook <kees@kernel.org>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>,
<mark.rutland@arm.com>, <oleg@redhat.com>, <luto@amacapital.net>,
<wad@chromium.org>, <peterz@infradead.org>,
<ada.coupriediaz@arm.com>, <linusw@kernel.org>,
<yeoreum.yun@arm.com>, <kevin.brodsky@arm.com>,
<anshuman.khandual@arm.com>, <james.morse@arm.com>,
<thuth@redhat.com>, <vladimir.murzin@arm.com>, <tglx@kernel.org>,
<broonie@kernel.org>, <liqiang01@kylinos.cn>,
<ryan.roberts@arm.com>, <pengcan@kylinos.cn>,
<kmehltretter@gmail.com>, <linux-arm-kernel@lists.infradead.org>,
Shuah Khan <shuah@kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>,
<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH] selftests/ptrace: Add PTRACE_SYSEMU_SINGLESTEP syscall-exit-stop test
Date: Thu, 24 Sep 2026 12:11:31 +0800 [thread overview]
Message-ID: <bbd65e4d-8096-4939-8308-f0f54c5cb3bc@huawei.com> (raw)
In-Reply-To: <20260922195719.i.211-kees@kernel.org>
在 2026/9/23 3:57, Kees Cook 写道:
> ptrace(2) states that no syscall-exit-stop occurs when a tracee is
> continued with PTRACE_SYSEMU or PTRACE_SYSEMU_SINGLESTEP. arm64 gated
> its syscall-exit report on
>
> flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP)
Hi Kees,
The original fix description is a bit off: on arm64 there is no extra
syscall-exit-stop; instead, there's an additional pseudo single-step
injection.
As sashiko pointed out, as commit ac2081cdc4d9 ("arm64: ptrace:
Consistently use pseudo-singlestep exceptions") described, for
PTRACE_SYSEMU_SINGLESTEP, arm64 still needs the pseudo single-step
because its hardware single-step state machine is fast-forwarded over
the SVC instruction.
static void report_syscall_exit(struct pt_regs *regs)
{
...
if (test_thread_flag(TIF_SINGLESTEP)) {
/*
* Signal a pseudo-step exception since we are stepping but
* tracer modifications to the registers may have rewound the
* state machine.
*/
ptrace_report_syscall_exit(regs, 1);
-> user_single_step_report(regs);
}
}
https://sashiko.dev/#/patchset/20260922035510.1090299-1-ruanjinjie%40huawei.com
>
> and ptrace_resume() clears SYSCALL_TRACE for both SYSEMU requests while
> PTRACE_SYSEMU_SINGLESTEP additionally sets TIF_SINGLESTEP, so the
> single-step bit alone produced a stop that must not exist. Nothing in
> tools/testing/selftests covered this.
>
> Detecting the extra stop is less direct than it looks. The report is
> emitted with step=1, so ptrace_report_syscall_exit() dispatches to
> user_single_step_report() rather than ptrace_report_syscall(), and it
> arrives as a plain SIGTRAP indistinguishable by signal from the
> legitimate single-step trap: neither PTRACE_O_TRACESYSGOOD nor
> PTRACE_GET_SYSCALL_INFO separates the two. What does separate them is
> the PC. The redundant report fires before the tracee has moved past the
> syscall instruction, so it lands on the PC of the syscall-entry stop:
>
> [0] sig=133 SYSCALL-STOP pc=0x41ec28
> [1] sig=5 trap pc=0x41ec28 <-- must not exist
> [2] sig=5 trap pc=0x41ec2c
>
> A fixed kernel reports pc=0x41ec2c already at stop [1]. The test
> therefore asserts that the first stop after the syscall-entry stop is at
> a different PC, which tests the consequence rather than the mechanism
> and does not depend on how many pseudo-step traps follow.
>
> PTRACE_SYSEMU is used to reach the syscall-entry stop, as single-
> stepping there costs one stop per instruction and takes roughly 200000
> stops. Architectures without a PC accessor here, or without SYSEMU
> support, skip rather than fail.
>
> Build tested ARCH=arm64 with GCC aarch64-linux-gnu 16.1.0, ARCH=arm
> with GCC arm-linux-gnueabihf 16.1.0, and ARCH=x86_64 with GCC 16.2.0.
>
> Tests passing on ARCH=arm64 under qemu-system-aarch64, and the same
> test fails as expected on v7.3-rc2 without the fix[1]:
>
> # entry stop pc=0x41ec28, next stop sig=5 pc=0x41ec28
> # Expected next_pc (4320296) != entry_pc (4320296)
> not ok 1 sysemu.no_syscall_exit_stop
>
> An AArch32 build of the same test on an arm64 kernel reproduces the
> failure identically, covering the is_compat_task() path. It also passes
> on x86_64, which already uses generic entry, so the test does not report
> a false positive against a correct implementation.
>
> Link: https://lore.kernel.org/all/20260922035510.1090299-2-ruanjinjie@huawei.com/ [1]
> Assisted-by: LLM
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> tools/testing/selftests/ptrace/Makefile | 3 +-
> .../selftests/ptrace/sysemu_singlestep.c | 176 ++++++++++++++++++
> tools/testing/selftests/ptrace/.gitignore | 1 +
> 3 files changed, 179 insertions(+), 1 deletion(-)
> create mode 100644 tools/testing/selftests/ptrace/sysemu_singlestep.c
[...]
> +TEST_HARNESS_MAIN
> diff --git a/tools/testing/selftests/ptrace/.gitignore b/tools/testing/selftests/ptrace/.gitignore
> index f6be8efd57ea..792c81f804c0 100644
> --- a/tools/testing/selftests/ptrace/.gitignore
> +++ b/tools/testing/selftests/ptrace/.gitignore
> @@ -4,3 +4,4 @@ get_set_sud
> peeksiginfo
> vmaccess
> set_syscall_info
> +sysemu_singlestep
--
Best regards,
Jinjie
next prev parent reply other threads:[~2026-09-24 4:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 19:57 Kees Cook
2026-09-23 11:07 ` Oleg Nesterov
2026-09-24 4:11 ` Jinjie Ruan [this message]
2026-09-24 23:56 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bbd65e4d-8096-4939-8308-f0f54c5cb3bc@huawei.com \
--to=ruanjinjie@huawei.com \
--cc=ada.coupriediaz@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kees@kernel.org \
--cc=kevin.brodsky@arm.com \
--cc=kmehltretter@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=liqiang01@kylinos.cn \
--cc=luto@amacapital.net \
--cc=mark.rutland@arm.com \
--cc=oleg@redhat.com \
--cc=pengcan@kylinos.cn \
--cc=peterz@infradead.org \
--cc=ryan.roberts@arm.com \
--cc=shuah@kernel.org \
--cc=tglx@kernel.org \
--cc=thuth@redhat.com \
--cc=vladimir.murzin@arm.com \
--cc=wad@chromium.org \
--cc=will@kernel.org \
--cc=yeoreum.yun@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®