From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (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 2F4A9239085 for ; Fri, 7 Aug 2026 02:14:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786068862; cv=none; b=os7Z9MW+23WN49SJWRTGD4ro+U4SxsLqMytctYCfxoVeXa36u+PmTC6wrUbdCVVqQP8cAMfhjcDui7YDdXSzgePSYpSI3n02/N1Z+VkQsWkXeXi4l0U6Y+hnni2waKMDzRdBA/TR+YsgzRnOMsSfP0Gh2qDG5E4ODHiM2Vo94fk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786068862; c=relaxed/simple; bh=Vz8713O1VDuMi4IMF5LHsh/OWeLwJuomQeh6KXB1Dik=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=KLVz7t+NkHUpIogiHEF0kk2oxkbHJ+xDQX8fRuZLAEYHWcEmu12cMOaGBwmzKaivQvTpziC8Tih+aUscYpyumtjBWosr7v84A6AdLjUGlfjfy/gMX20igW7y3mQODjf5ttlr2GTc7Zn+VS3ndEoMPXVsp/YZ5d3K0eOGjTiAyRA= 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=QzCOLrSW; arc=none smtp.client-ip=113.46.200.221 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="QzCOLrSW" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=PxxBm9riIIsqg0ISsYIrDF15BXAKmrDFgGq82nvty8o=; b=QzCOLrSWPoqjevlp9E5y+EW3y5EAZv0Afdvgic+jOVhecaiJP9baI0dEHJjjY0ewOIUYBGGt3 t/cR/suW6AYRv1cSn0mdiEVxds51fYGS4Mr3IUm2SFJp83euOMT1K2tKuNgE731+KJi0Y5b9zby rHEQYxJov7aMCvnOWXgqQn8= Received: from mail.maildlp.com (unknown [172.19.163.0]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4hGS9m38GlzRhWL; Fri, 7 Aug 2026 10:03:40 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 7F16140537; Fri, 7 Aug 2026 10:14:12 +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; Fri, 7 Aug 2026 10:14:11 +0800 Message-ID: Date: Fri, 7 Aug 2026 10:14:10 +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 From: Jinjie Ruan To: Russell King , Kees Cook CC: , , , , , References: <20260725091452.1875627-1-ruanjinjie@huawei.com> <864b868e-04b5-4187-9b93-72d476390906@huawei.com> In-Reply-To: <864b868e-04b5-4187-9b93-72d476390906@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To dggpemf500011.china.huawei.com (7.185.36.131) 在 2026/7/27 17:38, Jinjie Ruan 写道: > > > 在 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 Hi all, Is there any new thoughts or opinions? Any feedback or suggestions would be greatly appreciated. Thanks, Jinjie Ruan > >> 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. >> >