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 577B8C52D7C for ; Thu, 15 Aug 2024 15:46:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7E8B6B0156; Thu, 15 Aug 2024 11:46:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E55CE6B0157; Thu, 15 Aug 2024 11:46:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D44586B0158; Thu, 15 Aug 2024 11:46:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B46B86B0156 for ; Thu, 15 Aug 2024 11:46:17 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4A594A166A for ; Thu, 15 Aug 2024 15:46:17 +0000 (UTC) X-FDA: 82454906394.18.4AD9452 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 8298E40018 for ; Thu, 15 Aug 2024 15:46:15 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZQHxQvc5; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723736716; a=rsa-sha256; cv=none; b=EtZpby8/L/Ul8VpTK1aYTuReyUdibtEovJ/qGRVC7VM57QoPlNDc2wcWTwOdQ+8DHlwEyZ OqnRXLRJGiIJ+KPEe9RoR6lhCREWWFTvf2tD7VYitNXFjgI8q275EaE6XpCVgMY7I00uC6 HRKslcJ9/fy66Jz6IbhUZykgCi8FHOQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZQHxQvc5; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723736716; 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=BYFRYjw64OMKIKT/BwRFxu1Hmyc7DxbUFi7LAiSg0dE=; b=OxtR8Ssy7EpqeVGdkAjrIwMESHPEvXOs2/F2OWYyLvlREFU0tXt4bVPBPmFSO6Gm7dZLOx wwa46uYx5SNUVuzYPxahB0fJ5EtBaAuybPKL9iIHMzVQGRQaIH65NeJej7BfWm4RWLVMhl aB2K6fKh3ooDjbsJALC9LxI7+uyk1aE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7C0A361EC0; Thu, 15 Aug 2024 15:46:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A925FC32786; Thu, 15 Aug 2024 15:46:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723736774; bh=OhahuUFfndYeeiIAqMoZWO/itLbhbmCl9Dektx2bSmw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZQHxQvc5mzqu6Xt9OdE1XNZLD70/O3dkcJiXZaxebgJDxx2JQVYIg435975yYCQQr l5jUPJ9oJMKRElz7Dpy6UeqrDFRWxrZL9GgVJl4lw07+FN4VZhWpX5TJn27GiUUmzn zflbVeq8Fynrs4ZZayXEmrP67CO7FB82ptXHbETuTJY707TwQqihr/CnxYOeOkK3Iq Dls40SNfnnISQ4sF8cCZV+d/wVSzh4VpXAdOpq9qVv/6PVrUYatD7Il2JO1i+4JRAP 0bkotokage4eWgXhiPbnrXkVCVs4p5DoijU6EnNn09pzgcTeB9heRVbuopXzrzYpak 8cbW3fI2l2ChA== Date: Thu, 15 Aug 2024 16:46:04 +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: <280e4455-9cf7-40e1-9114-7bb3aa9de868@sirena.org.uk> 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="GXfbjsfo8XCmDLMF" Content-Disposition: inline In-Reply-To: X-Cookie: -- Owen Meredith X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8298E40018 X-Stat-Signature: q6h5t589ugagwwyay5ge1diew91mc7n3 X-Rspam-User: X-HE-Tag: 1723736775-780118 X-HE-Meta: U2FsdGVkX18hdz12jElYt2KGsxtiGEWzrUuUSTRLphC8Zu20jamU6SeAjcm3GVHhe2DfLJT3Mvexw82rXZJZHBBry3Z23E+U8obtLEd4M37nsDHp/ZvxVIqrs+s5hlnTSXv9f8x2JXZwflYQytjIPx3BE5VVtTpCR2HZqZlnz/dA0srq1cs/bC07uN05NtlPHB3Q+7a3kcgwI5PxTRJ0ICpj1Zfx3Spt/fwmmECmluyNqh45bqfR6be+WRseuEj6uk+LupCgHhwN1V0RO5FGipkC0wdI0Bd4f4mf+g1zMH/RUvzfyVb7gOxq4nrW/kD4P05FtFXXe40Tb03btaVeJZlpHWg680BEND98FMOHYa8YnJKJV6jLsrdLBI8jbOkf3Za4nDzJxZPV2hTtUFTutaIFmW1R00ulN2TAxmWuB4IOtfY6Mse2mQWrViZRLTUywaByd/yWtWM7va6f0OcQXbUjJH+/FU28Lj+N3n9hzvxtWDRqD2MBl/57q5eI6m/qmh3pbqN1Be1hG6/tBj+QhwHuE83jWlOYeAp1ySc2D9abwnaMVGtn8H5L0p9JCh0OVftj6oGg1SqUwSeYsMItZZK0ue7tZkokB2f0uvRyqvS70tco4tZWXiisxKgfGyAWJC3U1zNj1c47+HqS6N9RorkKPI5mTIWuFvQxaPGoBMOwpVCTzruVp+s3a6KP/cQflZCNB1wLtrWv6+O/idNJ1eB0yliBdH9WDRuaAZACLhfJZx78aw2nEnvpH8n4Cz9io5T2vA1Ug8FUtdOwfLLiYIAnT+Z4CEOPTLJ48KMru+1Q3g7swj0zsMpTP5i78CVTuUyInc9QUjX3/gVCouEcIjxINGxEOQmHH6gQivkrp2dxcFIPUWChWvYV5PWTBD+gbM5B4LjxNcaqKaDjmBOmKK79JO9wsPJvk98Ua2U0I6UIcTsMXcTv7ROe4twMu0zRML7CAUqxaZ9utEJZPTY sdkZsd0e M5iRWXEuV7y2RZ7rIk49p9Y9mXpyY0TiTbTolpFoHH8zTZjQC8gL4vqUV10EbR5+wHFJ/dftdCfLK8bRYJ1KJkx7Iy9qCWcWUDdDLAKuSwcO5fqH0LPa1nKRBZzavd8ndcuyADvj/oX4bJDwm7msw/8BEnedymJxL0V9JzkVB4rXcPmKIqVz9xkZxr9vpyINYFq4Vy5jtjiM6iCegybTn+qOdVrpS/9lkpmX5cWXCR/dkC0J10TEMuuw0RXmD512vAnAIFzJCNFM7RgybOCEIl3KFKePo5MR0GWNjxUjk2GsARF7IBNwCFWzrsZYy0cthvo8bIfW2O5eehpI4J/I8YyGhPYYc0NZS2gZp 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: --GXfbjsfo8XCmDLMF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2024 at 04:33:25PM +0100, Dave Martin wrote: > On Thu, Aug 15, 2024 at 04:05:32PM +0100, Mark Brown wrote: > > 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 feature= s. > Hmm, so we really do get a clear "enable shadow stack" call to the > kernel, which we can reasonaly expect won't happen for ancient software? Yes, userspace always has to explicitly enable the GCS. > If so, I think dumping the GCS state in the sigframe could be made > conditional on that without problems (?) It is - we only allocate the sigframe if the task has GCS enabled. > > > Related question: does shadow stack work with ucontext-based coroutin= es? > > > 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 > Ah, right. Doing this asynchronously on the back of a signal (instead > of doing a sigreturn) is the bad thing. setcontext() officially > doesn't work for this any more, and doing it by hacking or rebuilding > the sigframe is extremely hairy and probably a terrible idea for the > reasons I gave. I see. I tend to view this as more adventurous than I personally would be when writing userspace code but equally I don't see a need to actively break things. There's no *requirement* to use libc... > So, overall I think making ucontext coroutines with with GCS is purely > a libc matter that is "interesting" here, but we don't need to worry > about. Yes, it's not our problem so long as we don't get in the way somehow. --GXfbjsfo8XCmDLMF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAma+IrsACgkQJNaLcl1U h9DSDwf/fvoSsWjkRUucDXlPXcS3xALg/zYnf2jri8K1FvhKbx6ExKFpnk/0g2BM wK2PwaNUJU1aco+sWt4qWO5BpC2IehhK4SayS1RosRQNYaC++NMOh2/8HVNEHE10 XYPyfSZwI+nnf/4yS6Zz1HdzVTbuTkNBtkWyJtEO+gVukwrqd8ZroQ0fuSBvQyOu ZmkniP6ouY5JUJvZtbLtaP0MurY44KnJyfZKbDuNyinTVw/SRukqIPVzy3RT0tTJ rYVAnu34kZUCOei6ztPt+st1eA0IfyO0JvM2DcPAY7ZI1JHi15NFj0P2SedICD9d gFptQBZcUxVlVAqy5L/gZ2G4JmaFVw== =AdhV -----END PGP SIGNATURE----- --GXfbjsfo8XCmDLMF--