From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 156DD3E63BB for ; Mon, 27 Jul 2026 09:38:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785145104; cv=none; b=dylllS5qr9l8Ph1DYF19p3yR+KmFRjt39Sba9m+WcBnYRAbUdjgqHozSMuFceF6oISunEiF2N4H3DQaIPWrHB3t+bJ7yg/V2hO80WUUohKfuZ9imRQg3fuSx/y2f4vusDOFHVcHUZfH/kz/3dGtQITBFd7fMmVbmocfOmNKjGmE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785145104; c=relaxed/simple; bh=TQ8GxGM8NnmVhH8dgeN2fmgG6Kfv0I/qLZ97dF69TJk=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=r2s6dlZVaJmI+aFhWWe10eZcDJyObsox7Tz8Qtvm2vn64z52o3P/KF8+pWX00w+ySCg3bBJHQYMgXxPDTpIAT6IY8RnUz4QX0Sh4kfvAvISxDWZ7hw+6OwYIjxrx5SO/eRkrLot1qAHMgwX82HjHwoKjK4+GA8VS4qLp3EmEcPE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=ROZKl1oE; arc=none smtp.client-ip=113.46.200.224 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="ROZKl1oE" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=eqaiH3/8gwogQlQcVPAl0be7CAknXLZAcjJ8p31U84s=; b=ROZKl1oE8jinXqesNLdqQKCfOo/NBj8u0+BLYgKThiJLP3HkX0LLBuv9DN/Bp3HGtiP/K0Kf8 smVPUru0I6nPAKJ2fHO8YGjKfVDJwJTSRF0eeHJ6S3sBx/fo1vTXBe9jtG1tudUJmFL+vBJVnrY OFVjwg94iTpaUhHg/0jr9lo= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4h7tZQ64hHz1cyph; Mon, 27 Jul 2026 17:28:46 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 379C64057C; Mon, 27 Jul 2026 17:38:11 +0800 (CST) Received: from [10.67.109.254] (10.67.109.254) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 27 Jul 2026 17:38:10 +0800 Message-ID: <864b868e-04b5-4187-9b93-72d476390906@huawei.com> Date: Mon, 27 Jul 2026 17:38:09 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ARM: ptrace: keep ARM_ORIG_r0 consistent with ARM_r0 after ptrace writes To: Russell King , Kees Cook CC: , , , , , References: <20260725091452.1875627-1-ruanjinjie@huawei.com> From: Jinjie Ruan In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To dggpemf500011.china.huawei.com (7.185.36.131) 在 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. >