Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <linux@armlinux.org.uk>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: oleg@redhat.com, wade_farnsworth@mentor.com, will@kernel.org,
	stevenrwalter@gmail.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: ptrace: keep ARM_ORIG_r0 consistent with ARM_r0 after ptrace writes
Date: Sat, 25 Jul 2026 10:44:28 +0100	[thread overview]
Message-ID: <amSFfCPV2jWfhGq0@shell.armlinux.org.uk> (raw)
In-Reply-To: <20260725091452.1875627-1-ruanjinjie@huawei.com>

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
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,
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?

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


      reply	other threads:[~2026-07-25  9:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25  9:14 [PATCH] ARM: ptrace: keep ARM_ORIG_r0 consistent with ARM_r0 after ptrace writes Jinjie Ruan
2026-07-25  9:44 ` Russell King [this message]

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=amSFfCPV2jWfhGq0@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=ruanjinjie@huawei.com \
    --cc=stevenrwalter@gmail.com \
    --cc=wade_farnsworth@mentor.com \
    --cc=will@kernel.org \
    /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