From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 BA6F837BE74 for ; Tue, 21 Jul 2026 14:05:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784642708; cv=none; b=N1sCuqI89PFeGBaqaRhP+P1UrpppancD/ils+sCAwkibMU7xkxAnpO6sVurHCTXrZbmUCxLn1ZhMBxSgKpIx8u200xMm9DSRyxeeIveWN53qug7pqk9se2Rmta3CzpI3wO/3ugPyUcHjjB78LoAbjfyk2wmpZvHbcjwDZ4DS2uk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784642708; c=relaxed/simple; bh=gB4kWpitZ0I/gFD3iO5K48SCSXAWUawJ+EddIgYyHbM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=APbigwTs+XRBQJ7s4m9G6bT5ROlCVgAEoORdRDUaoxzoOeeLe3hckqfFCLEJD9U6NWfXx4ngx+Ep4yhie0xIwQ6oKoNJfA9lJEEn+EW3QvwLELz7oH5Rej6pAy7k5FblmpWDFHxaokFBIlNfZque31W3o9PQLDWXfthyPvEn4eM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KSMdw/tP; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KSMdw/tP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E967D1F000E9; Tue, 21 Jul 2026 14:05:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784642706; bh=d8nGVDCT8nrnBM5hXodvr6ytY8ni1kRQkp0Y6K87ybY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KSMdw/tPhe2IZD0LT6nPHFeQYsQzRfom5nSFHCg3AC4uAHM2z3AXwwe3nLT9FOiQS ps2xxu93g7+JeHzzqRJQKjZdZE6dYwTAAiBawthwdl66GpzqJBNdjkicIT+4EpTXVL vZ9RuMua0mng2/WfrQPvjrebixP2succFbvlfTpTg/bm7Y6PgQ2Yj0EfI98Ld7o99O hWqXFdLjT8LkudaRp2hj28Wmp5nl56HQOd6ILZLo48Zu9Yvb/m5MpKt9vgSdqswIl8 KNF5vXGVg4i8xN0EMlnVJnbXrHx2Ae9QfOTd7zl460YrsqlMimJhRr3mLM4wdRW9tN LETm5kTtIDhrg== Date: Tue, 21 Jul 2026 15:05:01 +0100 From: Will Deacon To: Jinjie Ruan Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, kernel-team@android.com, linux-kernel@vger.kernel.org, Kees Cook , Mark Rutland , Yiqi Sun Subject: Re: [PATCH v2] arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates Message-ID: References: <20260716120640.6590-1-will@kernel.org> <178420908877.33796.2351583216856259313.b4-ty@kernel.org> <8d3d3ea7-b250-4022-8ed7-6d438b43a518@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d3d3ea7-b250-4022-8ed7-6d438b43a518@huawei.com> Hi Jinjie, On Mon, Jul 20, 2026 at 11:48:40AM +0800, Jinjie Ruan wrote: > On 7/18/2026 1:54 AM, Will Deacon wrote: > > On Thu, Jul 16, 2026 at 05:48:01PM +0100, Will Deacon wrote: > >> On Thu, 16 Jul 2026 13:06:39 +0100, Will Deacon wrote: > >>> When seccomp support was originally added to arm64 in a1ae65b21941 > >>> ("arm64: add seccomp support"), seccomp was erroneously called _before_ > >>> the ptrace syscall-enter-stop and therefore the tracer could trivially > >>> manipulate the syscall register state after the seccomp check had > >>> passed. This was subsequently fixed in a5cd110cb836 ("arm64/ptrace: run > >>> seccomp after ptrace") by moving the seccomp check after the tracer has > >>> run. Unfortunately, a decade later, that fix has been reported to be > >>> incomplete. > >>> > >>> [...] > >> > >> Applied to arm64 (for-next/fixes), thanks! > >> > >> [1/1] arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates > >> https://git.kernel.org/arm64/c/e057b9477232 > > > > Bah, I've had to revert this. I think Sashiko makes a good point here > > that the seccomp interaction is still broken when the filter is > > re-evaluated after the tracer stop, because that all happens inside > > secure_computing() so we don't get a chance to update 'orig_x0': > > > > https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org > > > > Yes, I also think the point raised by Sashiko is meaningful. > > After reviewing the relevant code, I believe that the issue Sashiko > pointed out regarding the compat task also exists. > > My confusion is that on arm64 compat mode, both audit and trace use > orig_x0, but the first parameter used for executing system calls is > regs->reg[0]. If x0 is modified at the system call entry point in ptrace > but orig_x0 is not modified, or if orig_x0 is modified but x0 is not, > then the first parameter for audit and the actual system call being > executed will be out of sync. Could there be any issues here? Is it the > responsibility of ptrace to ensure that orig_x0 and x0 are synchronized > at the system call entry point on arm64 compat mode? Even with orig_r0, I think compat suffers from some similar issues here. However, I really don't want to diverge from the arch/arm/ behaviour, so the 32-bit code should be fixed first if we want to change anything there. Having said that, I notice we're already different in how we invoke audit_syscall_entry() :( I also don't know what the correct behaviour should be when both r0 and orig_r0 are exposed to the tracer. I have a horrible feeling it probably all worked until the API in syscall.h came along, at which point orig_r0 was suddenly used for more than restarting. > Whether it is ptrace or the kernel, ensuring that orig_x0 and x0 are > synchronized at the entry point of a system call, I believe it is > reasonable to use orig_x0 as the first parameter of the system call > execution and pre-set an error code in advance, as this way orig_x0 > always retains the latest value of x0. > > diff --git a/arch/arm64/include/asm/syscall_wrapper.h > b/arch/arm64/include/asm/syscall_wrapper.h > index abb57bc54305..6b13d7c8ad95 100644 > --- a/arch/arm64/include/asm/syscall_wrapper.h > +++ b/arch/arm64/include/asm/syscall_wrapper.h > @@ -12,7 +12,7 @@ > > #define SC_ARM64_REGS_TO_ARGS(x, ...) \ > __MAP(x,__SC_ARGS \ > - ,,regs->regs[0],,regs->regs[1],,regs->regs[2] \ > + ,,regs->orig_x0,,regs->regs[1],,regs->regs[2] \ > ,,regs->regs[3],,regs->regs[4],,regs->regs[5]) I quite like this idea, but I think we'll have to limit it to native (64-bit) tasks. The 32-bit code in arch/arm/ looks like it passes regs[0] for the first argument and so tracers could easily be relying on that. I'll do that as a follow-up patch. > #ifdef CONFIG_COMPAT > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c > index 2535cae9413d..a978bab59924 100644 > --- a/arch/arm64/kernel/syscall.c > +++ b/arch/arm64/kernel/syscall.c > @@ -62,6 +62,7 @@ static __always_inline void el0_svc_common(struct > pt_regs *regs, int scno, int s > unsigned long work; > > regs->orig_x0 = regs->regs[0]; > + syscall_set_return_value(current, regs, -ENOSYS, 0); I don't think it's safe to do this unconditionally as tracers could be relying on reading X0 with ptrace to retrieve the first syscall argument. Will