From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 4DD173939A4 for ; Wed, 6 May 2026 09:19:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778059185; cv=none; b=OXRANjuAdaKePwcHdEdohjJ+BZSwLSK/87LTkkPWqnOXG0khG/sRMB/2IUY1SVYk0CrEA8XLUzVgo9+lhr5Binj3/Ma7PJ1CPX9++W1Oc/SC3KpN+J0rUztr5M+muY2QS0QRb8F0FuWtdOyRJXfRtOa2neAvRGbhXq1Zn4QqpFc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778059185; c=relaxed/simple; bh=7ZiNUBA55fPXWt2Zbpo9mdH2lVH0pXelf/nklN4T/T0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aBoM2GrHJHQOYU5TLyd713zMHWSnrSTjoHg/B7wZ9G6WGwoyP6+a/1V48JH7d1fiKv7wmXhfo4VmiIM5ArI5MHs4DbzDhMQf84HLLHmUZV3sHRj9TdmeLNHGhUFykbksV9zwUdOe1HpRBTBQaFRcEjDauRm33uPR5KvQ/3c/VbE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=a2+5mhfX; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="a2+5mhfX" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=j6IL/ss3Y8x+u4i8PpUFYL9uKyD/qSTFj96oAhsxiYI=; b=a2+5mhfXsYqjwb5n9M1cQeTM/k oK4uKxfhpc7jWMvfhz5ksp5uTuk4RKb72wO/UeGEhBgvkDqVaTaMKJJyhQMwXm15tcfvey+J0ocL8 Xft9WjfAKS6VgFYGZAAOfyksmNG5t3t3/wj1AR0hxbb1hfE2u7u2zjyuicM0zrROFgHFmNw8W3BXp oZidG2psKz2JzqcqoD/Mc8UcB7OKauhotRCOyINn+yU7MBJR5Q4EVT3jGq2BgyGqu32ceKMnCAvHg oT4K/sh7NbbOBM4ECf/HPnSyZtRlnTAMPw8Srk5HMDJBljPlkBtnbej/3/cU+/LpbdKgR/diyYpvQ 5Dfs/Xsw==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wKYPe-003UEa-1l; Wed, 06 May 2026 09:19:26 +0000 Date: Wed, 6 May 2026 02:19:22 -0700 From: Breno Leitao To: Mark Rutland Cc: Oleg Nesterov , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH] arm64/fpsimd: ptrace: zero target's fpsimd_state, not the tracer's Message-ID: References: <20260505-fix_ptrace-v1-1-36ac1f6d0bfb@debian.org> 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: X-Debian-User: leitao Hello Mark, On Tue, May 05, 2026 at 06:05:25PM +0100, Mark Rutland wrote: > Hi Breno, > > On Tue, May 05, 2026 at 09:02:13AM -0700, Breno Leitao wrote: > > sve_set_common() is the backend for PTRACE_SETREGSET(NT_ARM_SVE) and > > PTRACE_SETREGSET(NT_ARM_SSVE). Every write in the function operates on > > the tracee (target) - except a single memset that uses current instead, > > zeroing the tracer's saved V0-V31 / FPSR / FPCR shadow on every ptrace > > SETREGSET call. > > Sorry about this; this was my bad and definitely needs to be fixed. No worries at all. While investigating random coredumps in the Meta fleet with some colleagues, the randomness of the crashes reminded me of a similar issue I encountered 10 years ago, where floating-point and vector registers weren't being properly restored at context switch due to a kernel bug, and created a reproducer in commit 77fad8bfb1d2f ("selftests/powerpc: Check FP/VEC on exception in TM"). So, this class of bugs is not special, although *very* hard to debug. > > Due to FPSIMD lazy save/restore the wipe only takes effect when the > > tracer's CPU FPSIMD binding is dropped after the memset; the next > > return to userspace then reloads V0-V31, FPSR and FPCR as zero. No > > signal is raised and ptrace() returns success. > > You're right that the corruption of the tracer's state is often masked, > but I don't think the last paragraph describes the circumstances > entirely accurately (e.g. if the binding is lost *before* the memset(), > the issue can still occur). > > I think it would be better to say: > > The corruption of the tracer's saved FPSIMD state is not always > observable. Where the tracer's state is live on a CPU, this may reused > without loading the corrupted state from memory, and will eventually > be written back over the corrupted state. Where the tracer's state is > saved in SVE_PT_REGS_SVE format, only the FPSR and FPCR are clobbered, > and the effective copy of the vectors is in the task's sve_state. Ack! > > Fixes: 316283f276eb ("arm64/fpsimd: ptrace: Consistently handle partial writes to NT_ARM_(S)SVE") > > Signed-off-by: Breno Leitao > > This will need to be Cc'd to stable. > > With the fixups above (which I assume Catalin or Will can handle): > > Acked-by: Mark Rutland Thank you for the review. I won't respin it, assuming Catalin or Will can handle the message rewrite. Thanks again! --breno