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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0E98C5321D for ; Fri, 23 Aug 2024 22:01:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 284E2800D0; Fri, 23 Aug 2024 18:01:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 234E6800C8; Fri, 23 Aug 2024 18:01:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D674800D0; Fri, 23 Aug 2024 18:01:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E20CC800C8 for ; Fri, 23 Aug 2024 18:01:23 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8C2A41201DC for ; Fri, 23 Aug 2024 22:01:23 +0000 (UTC) X-FDA: 82484882046.21.E2FB4ED Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf05.hostedemail.com (Postfix) with ESMTP id 3B7C210000D for ; Fri, 23 Aug 2024 22:01:20 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="DJhUw/1q"; spf=pass (imf05.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724450372; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KW8SSl8QvH2IzZRm98kmt400IalCVO8kwfcaczSgJr4=; b=GfW/aRVuqaxqA0ndLH9z0SHi39qKo1NWsAQgPtnGPoX9AEzn4Ghi6/oDukOGaRT53LBETz aBYeIKVxrPyru7Co7cmrDfH+8oRnYynF13FYRBHHLf85dTNx5N9g4+VhpsAotZaOdAJbw7 zL6xDqrhvE+h9OW3fS8KXCFyZVwP79I= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="DJhUw/1q"; spf=pass (imf05.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724450372; a=rsa-sha256; cv=none; b=yMASZ9R8Co7Q6Qwdl5/s/+hrW+PKYgcGQUyb8OaWLM4/AOiEuAMQwyVaMCCZvrXUimeLuw Jwcs+jYz9wksU7lwHAbEiq5ggVuWvu98xZ8gKiHpy/mLS/t66sif2wU0N+dN6pA9ZlTgWM HmACLyfaAmr3GUVlma9n/yM3yighj24= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id CC9FACE1189; Fri, 23 Aug 2024 22:01:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71569C32786; Fri, 23 Aug 2024 22:01:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724450477; bh=4E2/SMw5ipU2qtwXN1Uwic3Rzbvi3xioIyGpbAx2lVk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DJhUw/1qZ9BDQyGdrwh4ZFy64bp7OwurHPaIZF/8dlHGGMyUg6oD3nsAesh264NNS FoGyn2Rq2QL39OrogIEFtmo21ioxgFBgEj7Es9kG5Qpgra3wSXqqpYQ1pNK2A8IoYg Z8fN8zNIL9aOQlXGKDnm0SrmFwR/DdFSAkSXCqRoUqve0c9CIlohY5Kez50qcxZXm+ BBy4p4qNCrGMIXT5+V5RxKrFG95GKkg8ilN9BZLYBhNJwhkvW2QkCMhzkT8j4erCII zjx/mdrol0O8/FIK5z9vPsPhmzvc3K733r3dtwz1kN8Njo8cs83m645QMmL+XqdHr7 WVHT/FDFTov3Q== Date: Fri, 23 Aug 2024 23:01:13 +0100 From: Mark Brown To: Catalin Marinas Cc: Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , Yury Khrustalev , Wilco Dijkstra , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v11 25/39] arm64/signal: Expose GCS state in signal frames Message-ID: References: <20240822-arm64-gcs-v11-0-41b81947ecb5@kernel.org> <20240822-arm64-gcs-v11-25-41b81947ecb5@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BjuuYVXdnzsl9n3l" Content-Disposition: inline In-Reply-To: X-Cookie: Your love life will be... interesting. X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3B7C210000D X-Stat-Signature: h1oyhptikakh9o5b881e3ft7a7iqdxcr X-Rspam-User: X-HE-Tag: 1724450480-127834 X-HE-Meta: U2FsdGVkX1+e8+Wt+jUE8kSNkUo2otNGQOgF6CHx/qy+BOMGOxhLlVUfleuyK5IqJQM1DbC/4bzzw23SkUFQmVCe8FWGplAYy6WPVMbOSjvL+ssgowVV9pH+tdJhxiHe/GbloFZ7NzLJeJRNa7upC/kzb1awIV5H3nA6KV1bGeXSCgD96RCh7EMCfjBS8EwdcxiL4pQhjwn49rmoQwrGm2Z01JsHx+ZgYuCgy93S5/yGJcN70uOumWj1j7FPhLRYjCJkZz12OqVMQUjhibSOVYnS/oMYZJcXbHX3IyRKmeHK+1Lqy7UWKNhERf86ZDW2J92EStYz9Jlkoe/FIXl+9AQ9nYlLMGUjnpTAo2jsdQE+oTrymVCirgKcME4qqpvZKRSyZu3Mbt7KobMU50TBrQuIhI3qGszY4SWcNauL4a76AXIaRfxFPXn+v8YbfQ05hAVBlossyeeQ2/K/XIlomqkUwgjNE056SKmtUfIDm5ebPXAUBkdc04eVOAsYv6DFBLNVESWedN+g6RcDyQtpaKsy+X/sewbSoLSn0KPHQgUiTmuHlrBiky5MaSdKd/nxhVWfpm8f11DBOzmZ7Jf8ZXcoVWy7P/MaojHBiFUcIEPyFnEtW0FR8dtOJCiqLLtZG0+x2RdR2AYDugeOA6ZvCZu9klR9cRZc1ZtKhqfGnKlpKqnH/88vh9Bi0jjZAk4YZU0Db2gYeLVzValbOc29tw1PoU5i1JSC/AzTqy+bXxUxL1Tejl3YM2tY9bMOWEJfP0DSd5kmI8sqeKSPvbkFf/IL7FpEknMu0jzq+XnILUgHjmmrxxB+tNtQtU525sy/stwAT/N5yrClRGnF+CjYM8t2Q3k7hi1fDT8uW4K3QPoBsXlE6Ae2/KDVDCBn4/mS6ZrU6eIj6WS0c7vUKlHZUgji8KuXG4Yd0YWCsCQtB90OAMzKnqfFbIHbUiut+49ScGbMHSBTbtyNtOTzR1N hxhwuefs eszQ2vcCgg1+DsDxH3I8Ll3apZOwTVxn3i4Odx6iqfIAGJ5cYvjPbavn5hixcbTB2w0x4M3NNi5NaGcbbofzp6yOxcUkHKM5gGSsdR2bydFqbdKHYP9oO3gKuSG66wrciTyE8Jkacg8SzvtcrkBTzN4Lrc3HU/DcQGRtrR5dvJh5MK1q05vm1LIw1+wkziEC6Lr+kK7b7sjstBe/MVZGe9UkDcDOfC5BkjrrK6+w+hX0AtrKTSd82D4C9Bh1oyCguQyBx/Q2wgPgZjZBLUr86R79UVXvovuhl7iW3vF8/b2qgPN1ri4CTXjCXBGF3KB6q1JUTRMSc58OCCi+c/P64PX6XtAROc/xV+WwK3XJRxmTHodg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --BjuuYVXdnzsl9n3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 23, 2024 at 04:59:11PM +0100, Catalin Marinas wrote: > On Fri, Aug 23, 2024 at 11:25:30AM +0100, Mark Brown wrote: > > We could store either the cap token or the interrupted GCSPR_EL0 (the > > address below the cap token). It felt more joined up to go with the cap > > token since notionally signal return is consuming the cap token but > > either way would work, we could just add an offset when looking at the > > pointer. > In a hypothetical sigaltshadowstack() scenario, would the cap go on the > new signal shadow stack or on the old one? I assume on the new one but > in sigcontext we'd save the original GCSPR_EL0. In such hypothetical > case, the original GCSPR_EL0 would not need 8 subtracted. I would have put the token on the old stack since that's what we'd be returning to. This raises interesting questions about what happens if the reason for the signal is that we just overflowed the normal stack (which are among the issues that have got in the way of working out if or how we do something with sigaltshadowstack). I'm not clear what the purpose of the token would be on the new stack, the token basically says "this is somewhere we can sigreturn to", that's not the case for the alternative stack. > I need to think some more about this. The gcs_restore_signal() function > makes sense, it starts with the current GCSPR_EL0 on the signal stack > and consumes the token, adds 8 to the shadow stack pointer. The > restore_gcs_context() one is confusing as it happens before consuming > the cap token and assumes that the GCSPR_EL0 value actually points to > the signal stack. If we ever implement an alternative shadow stack, the > original GCSPR_EL0 of the interrupted context would be lost. I know it's > not planned for now but the principles should be the same. The > sigframe.uc should store the interrupted state. I think the issues you're pointing out here go to the thing with the cap token marking a place we can sigreturn to and therefore being on the original stack. > To me the order for sigreturn should be first to consume the cap token, > validate it etc. and then restore GCSPR_EL0 to whatever was saved in the > sigframe.uc prior to the signal being delivered. To me what we're doing here is that the signal frame says where userspace wants to point GCSPR_EL0 in the returned context, we then go and confirm that this is a valid address by looking at it and checking for a token. The token serves to validate what was saved in sigframe.uc so that it can't just be pointed at some random address. > > restore_gcs_context() is loading values from the signal frame in memory > > (which will only happen if a GCS context is present) then > > gcs_restore_signal() consumes the token at the top of the stack. The > > split is because userspace can skip the restore_X_context() functions > > for the optional signal frame elements by removing them from the context > > but we want to ensure that we always consume a token. > I agree we should always consume a token but this should be done from > the actual hardware GCSPR_EL0 value on the sigreturn call rather than > the one restored from sigframe.uc. The restoring should be the last > step. If we look for a token at the GCSPR_EL0 on sigreturn then it wouldn't be valid to call sigreturn() (well, without doing something first to unwind the stack which seems hostile and would require code to become GCS aware that wouldn't otherwise), if you do a sigreturn from somewhere other than the vDSO then you'd have at least the vDSO signal frame left in the GCS. You'd also be able to point GCSPR_EL0 to anywhere since we'd just load a value from the signal frame but not do the cap verification. --BjuuYVXdnzsl9n3l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbJBqgACgkQJNaLcl1U h9BLswf/SWEpbfZkH/LtOITztzCmYc/9r1ewDv1+OENkYT92eXaB9xbvJoP9TSK7 9L5zc2aRpMs8ND7Z79oBC2ukkLkNGlZgk50jrxAj/ABNYEwGhWr6WCEURjpJCREV waO+TZDL2bO84z/f9ES1W4aKPZfTVfDArJ7orEQM8OgkSdql3wE/D9qqw2FgivU+ pO4BYgkO67qg2p1/UIlgWEJAQAgYLI60IZkP2g6CawlFdze3kHo5cnIBh0Ou3sxa +HfHlY5BIjhQvlSdEx5GfhZuGdRSUlZdYwbbJGKAXt9sB80z6QbAet3BfFUGt83I CqP6WBYkc5NW8mLg/8gZCbn3Quh5Xg== =fp7z -----END PGP SIGNATURE----- --BjuuYVXdnzsl9n3l--