Re: [PATCH] ARM: ptrace: keep ARM_ORIG_r0 consistent with ARM_r0 after ptrace writes

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/7/25 17:44, Russell King 写道:
> On Sat, Jul 25, 2026 at 05:14:52PM +0800, Jinjie Ruan wrote:
>> When ptrace modifies r0 during a syscall-entry stop via PTRACE_SETREGS or
>> PTRACE_POKEUSR, ARM_ORIG_r0 is not updated.  This causes seccomp filters
>> and tracepoints to read stale arguments, which disagree with the actual
>> value dispatched by the kernel.  This is particularly critical for the
>> SECCOMP_RET_TRACE re-evaluation path.
>>
>> Fix it by synchronizing ARM_ORIG_r0 after every arch-level ptrace register
>> write.  The update safely skips syscall-exit stops (where r0 holds the
>> return value) and NO_SYSCALL states to avoid corrupting non-syscall
>> contexts. And use ARM_ORIG_r0 in audit_syscall_entry to fix data
>> inconsistency with seccomp/tracepoints
> 
> ARM_ORIG_r0 is intentionally not always the same as ARM_r0, just as

Hi Russell,

+Cc Kees.

In my view, the fundamental issue here is not that orig_r0 must be
consistent with r0, or that orig_ax must be consistent with eax, but
rather that the parameters or system call numbers used by seccomp,
audit, and tracepoint during system call execution are consistent
(reflecting modifications made by ptrace).

After checking the x86 implementation based on your suggestions, I still
think there is a slight issue with the arm32 implementation. In my
rudimentary understanding, the differences are as follows:

On x86, orig_ax is used uniformly everywhere on syscall entry path as
below, therefore, I think the code related to x86 32-bit is not problematic:

do_int80_emulation()
    -> regs->orig_ax = regs->ax & GENMASK(31, 0) // backup syscall
number to orig_ax
    -> syscall_32_enter()
        -> regs->orig_ax
    -> nr = syscall_enter_from_user_mode_work() // return orig_ax which
may have been modified by ptrace
        -> __secure_computing()
           -> syscall_get_nr() -> regs->orig_ax
        -> trace_syscall_enter()
           -> syscall_get_nr() -> regs->orig_ax
        -> syscall_enter_audit()
           -> syscall_get_nr() -> regs->orig_ax
    -> do_syscall_32_irqs_on() // Use orig_ax as the system call number
to execute the system call. This is consistent with seccomp, audit, and
tracepoint.

But on arm32, the usage of orig_r0 and r0 is not consistent at the
system call entry point.

-> str r0, [sp, #S_OLD_R0] // backup r0 to ARM_ORIG_r0.
__sys_trace
   -> syscall_trace_enter()
      -> secure_computing()
         -> syscall_get_arguments() -> regs->ARM_ORIG_r0
      -> trace_sys_enter()
         -> syscall_get_arguments() -> regs->ARM_ORIG_r0
      -> audit_syscall_entry()
         -> regs->ARM_r0
         ^^^^^^^^^^^^^^^
   -> use r0 to invoke_syscall()
         ^^^^

Based on a fix patch by Kees six years ago, I understand that system
call parameters are similar to system call numbers. If ptrace or seccomp
modifies the system call parameters, then at that time, the tracing and
auditing mechanisms also need to be able to see this change.

I understand that the semantics of seccomp and trace/audit are intended
to reflect the latest relevant data of system calls that are "actually
executed".

Link: https://lkml.org/lkml/2020/9/11/1282

> orig_eax is not always the same as eax in x86. These exist to allow
> syscall restart as ARM_r0 / eax will be overwritten when a syscall
> returns. I don't see arch/x86/kernel/ptrace.c::putreg32() needing
> this kind of fixup, so why does ARM?
> 
> ARM_ORIG_r0 is set to the value of ARM_r0 when a syscall is entered,

Yes, that's true.

> otherwise it is set to ~0 as for other exception cases, the value is
> meaningless (there is no syscall restart in that path.)
> 
> If one changes both ARM_ORIG_r0 and ARM_r0 during the syscall exit
> path to e.g. -ERESTARTSYS and then raises a signal against the user
> program, then is it not possible that do_signal() to then see that
> case, and as regs->ARM_ORIG_r0 would now also contain -ERESTARTSYS,
> call the syscall with the first argument set to -ERESTARTSYS rather
> than the user's actual value?

We should not modify orig r0 on the system call exit path ; instead, we
should modify r0 to change the return value.

Best regards,
Jinjie

> 
> Userspace has full access to both ARM_r0 and ARM_ORIG_r0, and can
> decide what it wants to do in the same way that userspace has
> access to eax and orig_eax on x86.
> 
> Please check how this is handled on x86.
>