From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DB823C47DDB for ; Tue, 30 Jan 2024 15:47:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IULOqwXjpKH5dQvy6+7zMyjscOPh6IZYg3txVG44fXQ=; b=AXCXmX7m6J/oq1 e6VGI3o0nBoRGPJqi8U1o2Wncto5n7UED+DsBU4JWUsds01PzIJpAvoKSOTg3vlybCpKHT9N5Q+N1 5W/4gz6+cj5j5R6H4FccArb29fbgr5ZV64lvQcdFsKT+A0XK7kMpJTX6ihD1pAUuKc7s4PraQzHHt Y+/6npt/Gpee8tYTmDeihTvQYUYvPa5aCWlK75o5ZFNb/NOZO/wVdwiwO63EohIigooVR1NJoDrPr JaYJk4pFSiXyOADk0nalSRqjGlCZYghw8dmYJnNDNKUPFeOJ4ownavSuzRstzwsMjewVtTnDvLJ33 nmmXkvPYudkpuseeQaWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUqKr-0000000HEXr-0rW1; Tue, 30 Jan 2024 15:47:41 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUqKo-0000000HEVy-0yyx for linux-arm-kernel@lists.infradead.org; Tue, 30 Jan 2024 15:47:40 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B2701DA7; Tue, 30 Jan 2024 07:48:15 -0800 (PST) Received: from e133380.arm.com (e133380.arm.com [10.1.197.58]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B3513F762; Tue, 30 Jan 2024 07:47:30 -0800 (PST) Date: Tue, 30 Jan 2024 15:47:26 +0000 From: Dave Martin To: Mark Brown Cc: Will Deacon , Catalin Marinas , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] arm64/signal: Don't assume that TIF_SVE means we saved SVE state Message-ID: References: <20240119-arm64-sve-signal-regs-v1-1-b9fd61b0289a@kernel.org> <20240130115107.GB13551@willie-the-truck> <7027bd80-1fea-493a-83d7-ffef4e548f08@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7027bd80-1fea-493a-83d7-ffef4e548f08@sirena.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240130_074738_438468_8887DCCC X-CRM114-Status: GOOD ( 28.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 30, 2024 at 02:53:45PM +0000, Mark Brown wrote: > On Tue, Jan 30, 2024 at 02:44:51PM +0000, Dave Martin wrote: > > On Tue, Jan 30, 2024 at 02:09:34PM +0000, Mark Brown wrote: > > > > That said if this is preempted ptrace *could* come in and rewrite the > > > data or at worst change the vector length (which could leave us with > > > sve_state deallocated or a different size, possibly while we're in the > > > middle of accessing it). This could also happen with the existing check > > > for TIF_SVE so I don't think there's anything new here - AFAICT this has > > > always been an issue with the vector code, unless I'm missing some > > > bigger thing which excludes ptrace. I think any change that's needed > > > there won't overlap with this one, I'm looking. > > > I'm pretty sure that terrible things will happen treewide if ptrace can > > ever access or manipulate the internal state of a _running_ task. > > > I think the logic is that any ptrace call that can access or manipulate > > the state of a task is gated on the task being ptrace-stopped. Once we > > ... > > > I haven't tracked down the smokeproof gun in the code yet, though. > > Yes, exactly - this feels like something that surely must be handled > already with exclusion along the lines that you're describing but I > didn't yet spot exactly what the mechanism is. I think the critical thing is the task_is_traced() check in kernel/ptrace.c. This seems to be what gates every ptrace call that requires a traced task (i.e., stopped under ptrace). So long as nothing during the delivery of a single signal can trigger a ptrace-stop itself, I think ptrace can't get in the middle of it. This would imply calling the signal delivery code recursively (not just raising one signal while delivering another). I'd be pretty confident that this is meant to be impossible from a design standpoint. > > From memory, I think that the above forced flush was there to protect > > against the context switch code rather than ptrace, and guarantees that > > any change that ctxsw _might_ spontaneously make to the task state has > > already been done and dusted before we do the actual signal delivery. > > This may be a red herring so far as ptrace hazards are concerned. > > Indeed, it's all about the current task and won't help at for ptrace. Agreed Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel