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 917B1C3DA7F for ; Thu, 15 Aug 2024 15:05:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1173B6B011C; Thu, 15 Aug 2024 11:05:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A0D86B011E; Thu, 15 Aug 2024 11:05:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAAFA6B011F; Thu, 15 Aug 2024 11:05:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CE48D6B011C for ; Thu, 15 Aug 2024 11:05:52 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8094341762 for ; Thu, 15 Aug 2024 15:05:52 +0000 (UTC) X-FDA: 82454804544.26.D19DED9 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf03.hostedemail.com (Postfix) with ESMTP id 308E620039 for ; Thu, 15 Aug 2024 15:05:48 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AKZYerGH; spf=pass (imf03.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723734292; 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=IsPXtFePtoOrVO4V+lj/gDV4IG4Bvd2KkrZd/s9Y57Q=; b=dADRB2WTUfQzBx9gNC3c6wCk0wDcGnYXJxv7S7cR5xqeTbCJD+wcDyk7K9v9DaLldRdcHI kZzss3EGfA2w2dXso8S609APxp6TDpkxtrBsGwhfNQk/R7Asb2KhnweJEVExcxB5V6mA9C +BtsHoT1h/nms8/Un0Chb9lG+CHrrx0= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AKZYerGH; spf=pass (imf03.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723734292; a=rsa-sha256; cv=none; b=2pR+ke/Si5uMOKxF/+61o0lCQJERy1pa1XmZ6T+j2CheVVpIdC6Z8DUCjfgHRtSVl26lTe 9TYS6Dwsi3t6IF/MczYrLkxZ6xpiMRx+qVW6wiKsVgx4P9lK4UsA6QXdoq7QxM83IdGQZh T8JudIZl10E65SnLD62CdCC0pFIosSE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D3535CE1CB1; Thu, 15 Aug 2024 15:05:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56C21C4AF0D; Thu, 15 Aug 2024 15:05:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723734342; bh=VaZmCxGBF8KztnlsWWYHsWkxQ+nObQmzwcHV6fkRBCE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AKZYerGHcjQDpXEtvnruAGu5zXDe7awbHeen5Mm3saiTtNbcwHPI2BNFcpGWaKLl7 YIKg6KnEFRVGaNPCZCbWvEPBvhVlfqikdVQyxH311a84xo7K2q0lWx4/oPE4spK+Gc uVkrd2SL+XZHxyR1/oBYNkBNcNnPIsk4aho61+F4Aysl+0A3Wz95fLmEsodqnvYA90 Y0JvpH7+0yNt6fPPLf1ogR/SXjp7qymrN/8ccZueeoHvawyYsYLYsLW2g+4m0kriSI 6xvFXlUgNCrp4sQx0OnVpPiV7ujihcrQde8PFl5rQyVaq2FkjbGlnZNsTfDFw1A+GF wKIh9mENd/rRg== Date: Thu, 15 Aug 2024 16:05:32 +0100 From: Mark Brown To: Dave Martin Cc: Catalin Marinas , 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 , 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 v10 24/40] arm64/signal: Expose GCS state in signal frames Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-24-699e2bd2190b@kernel.org> <7433e3d2-996a-45a0-b917-666a340ad109@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SmjZxCFLN11graeJ" Content-Disposition: inline In-Reply-To: X-Cookie: -- Owen Meredith X-Stat-Signature: fqjnpau4gqd6kujbxqnj7gznu5fzh6tr X-Rspam-User: X-Rspamd-Queue-Id: 308E620039 X-Rspamd-Server: rspam02 X-HE-Tag: 1723734348-482915 X-HE-Meta: U2FsdGVkX19zRO9jvfq69Pz5/wva/26EQqetSZnyJL8kq6L+T2Eafb4UWkFvavVAwyCho1rfCAtMd8YpzAE1XGPO/MANQE65V8Ct/LfMNBtm+BA1BR0PFO/UExy3fJ4vHUKWBZltzDQg8CF3+APc3lcGrtXF0yTB0qFy5Xt0116AGGSEmJsPsjJma0n6dbfmXEWESrYHQ2B1cl82uEQI2LDLK0Q6TRBE/VRNzc3a9pGogxlevOx/78RrlWIWGzWPlmGo/FaYZe2GKhprT5xDvAlNuConU30xRlmN4OzKL3dSysrUVAT0T6CsskkxxZzIn2Blndj2L5NEEHAEXsVOrKTptppLuo4dqghQtGPk4id1ECoDjlPmrGq1v2OlBM8wr4RcvWUIzY2kLyt8gfNWyNMTDaKe0FdlagLMPDnbxaaDalFokyltQcoLoLRTsIshfuxjHBUIjIRbvpZOnXlKbBsTwnP8FuVtq67SNw0huqDsI4QUCeYG9/gCksJEHZkTcROMMvn1GE2OU2h5waDz6oSq/5nynDrHSNvmfLcKPWby82ZEYsAkOQs3DjXQ2KYY7ElxysM5M26vr5+ypHDvWUCrdehwRv3udA+NKfkT0c7wFabgcFiLihST+Mhq6qcmZ/TtNN6XQRVn5UUDpmHBhZRzfzxmtWY2F/V0cA6miMxqiuKqsaS1x/Zn88Q/rWv8tUSRumXINq/gs0LEO92iLDFXzY74VxSgJVmenYKse6KJxsxNJVT1pi+6SvQ+XlO2VPxBCdWg+wQICbBjhxw9vj322skmTVTEt6xrhcGt5GfxVIM9YV0hhns/4wtYs3nqPlSaZ9Pd2rr+etxtpK9kP6B4Ugv0wBcVSVYqnfaUg6LtR6zPUd3AmE9+YuZOCC5FiciGkYGCGmXfpIFpN34TVGHBdJsU5SuZdUqAWLHhHmhsK8BtiqG9t3L6gwT6eRKAuLo/sAyYt5wXK+JbygK YKXGKQH6 W4bkzNPPb585ZXJPpTeokXVb1tjXpd6+rNHAe2tgsFwMfqTxMyoq+bRfI65lOhIMAZs86tdt8pg1RDj2Do6DBtLFbuHtsYy37mJg5gY3sKFOCyo1Fg0/uobQRWtOqvAcjXLfdGQ8Z3FWVOOhXDhmSgeuyD2m5FpyffvapohJkGSqOMowjDZ1HLUcfoboAgLsJWX85BUsBfr6nJUiJhf8HIl9LVCUy5w7ULJce2fTFeBVkH9DRxAAewCQRMFZTeyjosSZSgqp3Bu4o/y34SGtNosGQ4hHXwcGc9Zd0G1JapLJ9k5/XjckmyX7LMcr0lPvGAMFc/6Nac9DUxZPkeZPd+8uciGSdBeTNepQD 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: --SmjZxCFLN11graeJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2024 at 03:01:21PM +0100, Dave Martin wrote: > My thought was that if libc knows about shadow stacks, it is probably > going to be built to use them too and so would enable shadow stack > during startup to protect its own code. > (Technically those would be independent decisions, but it seems a good > idea to use a hardening feature if you know about and it is present.) > If so, shadow stacks might always get turned on before the main program > gets a look-in. > Or is that not the expectation? The expectation (at least for arm64) is that the main program will only have shadow stacks if everything says it can support them. If the dynamic linker turns them on during startup prior to parsing the main executables this means that it should turn them off before actually starting the executable, taking care to consider any locking of features. > > > Is there any scenario where it is legitimate for the signal handler to > > > change the shadow stack mode or to return with an altered GCSPR_EL0? > > If userspace can rewrite the stack pointer on return (eg, to return to a > > different context as part of userspace threading) then it will need to > Do we know if code that actually does that? IIUC, trying to do this is > totally broken on most arches nowadays; making it work requires a > reentrant C library and/or logic to defer signals around critical > sections in userspace. > "Real" threading makes this pretty pointless for the most part. > Related question: does shadow stack work with ucontext-based coroutines? > Per-context stacks need to be allocated by the program for that. Yes, ucontext based coroutines are the sort of thing I meant when I was talking about returning to a different context? =20 > > be able to also update GCSPR_EL0 to something consistent otherwise > > attempting to return from the interrupted context isn't going to go > > well. Changing the mode is a bit more exotic, as it is in general. > > It's as much to provide information to the signal handler as anything > > else. > I'm not sure that we should always put information in the signal frame > that the signal handler can't obtain directly. > I guess it's harmless to include this, though. If we don't include it then if different ucontexts have different GCS features enabled we run into trouble on context switch. > > > Is the guarded stack considered necessary (or at least beneficial) for > > > backtracing, or is the regular stack sufficient? > > It's potentially beneficial, being less vulnerable to corruption and > > simpler to parse if all you're interested in is return addresses. > > Profiling in particular was mentioned, grabbing a linear block of memory > > will hopefully be less overhead than chasing down the stack. The > > regular stack should generally be sufficient though. > I guess we can't really argue that the shadow stack pointer is > redundant here though. The whole point of shadow stacks is to make > things more robust... > Just kicking the tyres on the question of whether we need it here, but > I guess it's hard to make a good case for saying "no". Indeed. The general model here is that we don't break userspace that relies on parses the normal stack (so the GCS is never *necessary*) but clearly you want to have it. --SmjZxCFLN11graeJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAma+GTsACgkQJNaLcl1U h9Cb8wf/XCjGckqPDQqfMA0CTLZ811XV2dX1kqvju9JAXl44DN3khpUuEAkktoKg KbrTL623QOjWbXYNgob5OLdQY42g++1RsuH62wKmX2kr080OWTmKFnRRROJzBftx t9l70dd63SnOG7orRLDAACk/Api5Gr9PnCVZ/wc5DvzpD8Oiu8JxTTYgBlYkE/AH 7ypTKtVlPzjfwNV95yhvqPFkoOPSsnSaQPBgZSthZf6LL6iT2IymUV01zdLYCuCL YyeXxml1r7AkEjF2dAncCRH1A9ZwpmjpMiF/GsjJBzX4hvu2cS+LUiYodWA2fO1Q 6+/7fZ2S/ywynEbWYd2kLO2E/zQWMg== =78We -----END PGP SIGNATURE----- --SmjZxCFLN11graeJ--