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 DEA7FE77378 for ; Mon, 2 Oct 2023 19:49:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 482716B0180; Mon, 2 Oct 2023 15:49:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 432886B0181; Mon, 2 Oct 2023 15:49:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FA206B0182; Mon, 2 Oct 2023 15:49:43 -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 212E76B0180 for ; Mon, 2 Oct 2023 15:49:43 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E1FD01A0445 for ; Mon, 2 Oct 2023 19:49:42 +0000 (UTC) X-FDA: 81301561404.30.B181FF1 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf21.hostedemail.com (Postfix) with ESMTP id 0B5C21C0006 for ; Mon, 2 Oct 2023 19:49:40 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kKXwOWMa; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of broonie@kernel.org designates 145.40.68.75 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=1696276181; 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=O7KyxLpElC1Kmd7M3B7OSWlskD2qA8r9ggMVZ39Nl3w=; b=Ch96oiF/o7nPcCNnieGm4TdgzB45nB8/6t84OzOHEnzGmAKMKEt9hUejpIwS02vNN9gNoH Z2cyOWWLZSGTTxIwSEHWuFwYmBDVLc7+aSMj1GbfgO5bOylC4HEvDW/HlAOet9F9bd0se0 sRncpMtW/jL8DTEKOlZq3RVtGrMSTpE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kKXwOWMa; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of broonie@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696276181; a=rsa-sha256; cv=none; b=iobHZnYDkf2wPsafClxrisSjbxTerIVGwpvHVxpruLFWukLurB4R9wAiys2NXgXtB6dyPs hyiygld55LMk22x0qa3+rgdBJwCAr1ZdrzdxArqveqeMZVwBC/Hp+Q0CvWp2OA57mhQdaS P+ygMZA8pNzqGzRsKFJUb1unnHM7Wv0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id C8A3FB81611; Mon, 2 Oct 2023 19:49:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54401C433C8; Mon, 2 Oct 2023 19:49:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696276178; bh=LSyryQpZ8HNgK9TYVlNlqsE7lc5WMeTA4wsbmFm3L9s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kKXwOWMamRR/cwKFQzaeuZxYaQcA9pAOs++Wwik8ym5z22A7p3jNfV2rtHHzHNGC8 0lheJnqFSM7L6ZYmOforDPwwL/34IFYGrLkgotPsqeADaR3LXrKS8hbZ/2FUWkkJNw LPB+4mw1S7AfYmbFrEOJSjjElJ1mJhnH1mh9IY7IFLod4E9pim8Rsyo+JVFASECtPU 7BJQzLgZfLui0jLmBNFFeGBb8GdQjLybPYSQZzcK78Be1ldmSWDG2t/IIul/GB9ivp PcFV0VmXEr1/HmvuFQ9ZAmkhFvUg2DUTdbV6RN72AGy3lVH9mUOZ3mPBUhvBoTKNPk Q6T67HS2ww7dA== Date: Mon, 2 Oct 2023 20:49:29 +0100 From: Mark Brown To: Szabolcs Nagy Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , 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 v4 03/36] arm64/gcs: Document the ABI for Guarded Control Stacks Message-ID: <38edb5c3-367e-4ab7-8cb7-aa1a5c0e330c@sirena.org.uk> References: <20230807-arm64-gcs-v4-3-68cfa37f9069@kernel.org> <43ec219d-bf20-47b8-a5f8-32bc3b64d487@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gCNrmYlrm9/empAg" Content-Disposition: inline In-Reply-To: X-Cookie: Postage will be paid by addressee. X-Rspamd-Queue-Id: 0B5C21C0006 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: w9a1usqyay9nu71aco85j9i479gwykah X-HE-Tag: 1696276180-369219 X-HE-Meta: U2FsdGVkX1/drioujmZaL+vMfAeOX4tB6vMkzTpEgtn7bSpz0e759Tg8GiXla9XpRZqcuQWjAlbkXavn9cmofjLQmx3gMj98wphj5lX2XVRofTHVhv6RzrYp0+M6Azk6fRKJ90P6yoQLJkRQ74MCtXNEt4k1jE3WcUN1iipC4XbpHjRMCbF1bPGpltXBUugvUe6jo/+k/qJ0lV0GtC6cnncobrYmuBVe2zB5htzscztvv3DTAbk9E/kKlp+B9uri03Y2sma0iHCb/sNXjDiTZKhj+5m/4gVbyxuYVyD4zq9SQMUThPTaS/T9Go4261Ru75OZcQTlKok+wroQdxMij86nTgXRS7wg00e3oQBtN2VsJg794aAi0Y0iBmP5VRjJLlQAJa5ymO4+lCySzPafejtKVP1pzWFMHLFGz/FQiNbdqexNiZmqxzMEJ1MoteY1Fjv+I4RZ98H3qoi9/tInyhya4j+JlJOv1iyCIrUU6a9U5aVAQOsdfqVZibUeU+aIa/ieviweAxGx/2ALfQJs3ak2j4EpQQIScYIqvMpMeRIrB1E7SRnEbbb2Q0Eqp78WEHUYzcyLoljkmg/mDxmue2xvgcw6bKbiR1nkfhB9G9BZqVZ3kCHqmzcF8j2AD2TaqbHDve/3B/uX5m6cLioHjxh2gArk/vF1BcWTXPkfqkZfKeWvyFqplchag1Jl551CP2n5wKOP76cLqWXY2M6ODNDpYtLtnpj5JoIGyTuNNHwQAM5HdrD1suMb7dWxpClkYP2IsKmmU9iso8qaFCouGH2/OutVo5BWpR4FNwiFw1zv5ma7Bv6j/4C5Nyy8Zzscb4aY68CeYe7sR8EnSzBGYHs2ODh0FcY3W7Fnb/9X2JVoeQ8T3CBimINtJuIwLfghOISwJGxxOQWldLZmARVNJDtlCpIVOIm2+D+l5Q89B54gQmXczNB2ypZF8A6CGgATYQjqN8s5ekkcuAGa63L DmBed4J+ ZsV+ZXAT6/MQ2svR/Wx6+f1Q3qzrS1lct+F9QQ+OfFrtDv/JnhAJNBqQs8L8pKLsnbqNADJMuaaH47yxiY2naSTv8Akb5CN2Xd5MHuRdaC7N6TySSbFY8KQ9jEu25VzHS51G5VR/AKLNvtguwpr+KVlT7Q9v11c+M8yXQ0MoebYMPj8hjHcixPt9G+uzkD4kHq/Y+HijX9dYRk+FvqSZPk7Qs7iP6bwr8AsWxoDdES63rNCIKrBldMq5K1uCTW8iApLM4IHHYaNHGsSXGJCVtShW0UrYWtHWZUI+acdwCLOcsi7FU9RomE0rzdGtLsd57WaeX2ZXL1l8c+6k= 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: --gCNrmYlrm9/empAg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 28, 2023 at 05:59:25PM +0100, Szabolcs Nagy wrote: > The 08/23/2023 14:11, Catalin Marinas wrote: > > > and there is user code doing raw clone threads (such threads are > > > technically not allowed to call into libc) it's not immediately > > > clear to me if having gcs in those threads is better or worse. > i think raw clone / clone3 users may be relevant so we need a > solution such that they don't fail when gcs args are missing. Are we sure about that? Old binaries shouldn't be affected since they won't turn GCS so we're just talking about new binaries here - are there really so many of them that we won't be able to get them all converted over to clone3() and GCS in the timescales we're talking about for GCS deployment? I obviously don't particularly mind having the default size logic but if we allow clone() then that's keeping the existing behaviour and layering allocation via clone3() on top of it which Catalin didn't want. Catalin? > userspace allocated gcs works for me, but maybe the alternative > with size only is more consistent (thread gcs is kernel mapped > with fallback size logic if gcs size is missing): If we have size only then the handling of GCS and normal stack in struct clone_args would be inconsistent. Given that it seems better to have the field present, we can allow it to be NULL and do the allocation with the specified size but it should be there. > > An alternative would be for the clone3() to provide an address _hint_ > > and size for GCS and it would still be the kernel doing the mmap (and > > munmap on clearing). But at least the user has some control over the > > placement of the GCS and its size (and maybe providing the address has > > MAP_FIXED semantics). > the main thread gcs is still special: the size is provided > via prctl (if at all). Either that or we have it do a map_shadow_stack() but that's an extra syscall during startup. --gCNrmYlrm9/empAg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmUbHsgACgkQJNaLcl1U h9Dyngf9Hy8AfP5kC/6h6EPVo7EVDeJ1A4cbGRBtR61F+kO0Gknu6S0AxnHkfkgt cODaJDIw85fav0lGTTx8Rlr/77kzihHWSNLwnyAaR1gPYzRgqM/XBdwf9M6mnT7I 907nXSNYnfB1pE+8Be1LmcXX8hbHhr6l3K+FT5vZQTcpEAGrxAv7xLNEZ7xMkqV0 PPa+7hjf+9MpBcZQbqjK+KpoCWdTAZkTcnqpKQApUqiAbs5aeKuDfqulxl4eQ7IF 4y3g5jbZpwsCSjlxNnQaT+K8cof3zDuHUV6Hf4rpNA4XfwybEbSPNYD8zZ8TYzbj 1IGtDcFokNQ4Y0FbRpYBRx621claGQ== =f6SF -----END PGP SIGNATURE----- --gCNrmYlrm9/empAg--