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 13CF1C04A6A for ; Wed, 2 Aug 2023 16:27:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 68E3D2801C4; Wed, 2 Aug 2023 12:27:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 617562801AA; Wed, 2 Aug 2023 12:27:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 490E62801C4; Wed, 2 Aug 2023 12:27:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 33F532801AA for ; Wed, 2 Aug 2023 12:27:58 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E4A0F160F5A for ; Wed, 2 Aug 2023 16:27:57 +0000 (UTC) X-FDA: 81079696194.16.586589B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id A737F14000D for ; Wed, 2 Aug 2023 16:27:55 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oOEm7306; spf=pass (imf26.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 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=1690993675; 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=7+UMt2tLEKIPU5B8rZsd8ytQDTVvALAQPKiFFqQ3Lz4=; b=2V9ae6Q7+e9hMm8qZbgzxZSDCupVh5MAkbbjGqJCUzctSU9osu701V5vktTsGRWb7IxpTy J80jd4bJV0ECOz/19QmHp9cNOwlNHgPcSTFdjVHb3ZPpeSnrpGnYy6esOV6880L84Xtcbf JoDOnWOfPHSXyzdKHMtxl+D4mg/ypgE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oOEm7306; spf=pass (imf26.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 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=1690993675; a=rsa-sha256; cv=none; b=3cc61ueILeovfhVnQo+eRwc3Zi5eB3VYVXIyukWtDKjKyHzg/DgZDGkEErq4X23ng3GFF4 5dRM08eXsp1P8ELC+XnbwlbsKsEUvM5Tn7BHvngIpC5ssG9E2+YgxUwD6hRLlL7NaBZuHK OLBy97thwWjqZiJyYpMGc2WZ8GuPJxM= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 968AD61A25; Wed, 2 Aug 2023 16:27:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F6D2C433C8; Wed, 2 Aug 2023 16:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690993674; bh=IypduYRdhJJTtTi/vdjRUEIIDyW7f/veSqGdfghGaM4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oOEm7306/htJKG4CId0R41FGls9huoRDB8SC5RAspSExEJWc+HyVpGhFGv4Wg+PCF DNKER8c6sgtmUjA+ZIyHRtYIYq7s1L8BFIQctpG47gXwN8Vk7wWF9EhSMrNWfwBrKa xvHTe4Pf4ZHfn6zJaolp23r8l3t+iwOVtR8qQQwVdEQ3yiLL1IIdDsYkwudrO92YiE FYGqNhGsI2AB015N0akL8QNC7MUhH864UCZeGRUpoIjIcQa5QkuuS1mcndY8IYStIr JLUyc346bw68jZ6ki7rhKVwxWbLrfo45Bl68nj4Ylkf3MXxPTk91QSuMRGtzpudBB6 QKxmNsVU4IKRg== Date: Wed, 2 Aug 2023 17:27:44 +0100 From: Mark Brown To: "Edgecombe, Rick P" Cc: "corbet@lwn.net" , "ardb@kernel.org" , "keescook@chromium.org" , "Szabolcs.Nagy@arm.com" , "shuah@kernel.org" , "maz@kernel.org" , "james.morse@arm.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "akpm@linux-foundation.org" , "catalin.marinas@arm.com" , "hjl.tools@gmail.com" , "paul.walmsley@sifive.com" , "linux-mm@kvack.org" , "palmer@dabbelt.com" , "oleg@redhat.com" , "arnd@arndb.de" , "ebiederm@xmission.com" , "will@kernel.org" , "linux-kernel@vger.kernel.org" , "suzuki.poulose@arm.com" , "kvmarm@lists.linux.dev" , "linux-doc@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kselftest@vger.kernel.org" , "linux-arch@vger.kernel.org" , "oliver.upton@linux.dev" , "linux-riscv@lists.infradead.org" Subject: Re: [PATCH v3 21/36] arm64/mm: Implement map_shadow_stack() Message-ID: <475f31e1-0f6f-44a9-b93a-540c1d43e1bb@sirena.org.uk> References: <20230731-arm64-gcs-v3-0-cddf9f980d98@kernel.org> <20230731-arm64-gcs-v3-21-cddf9f980d98@kernel.org> <5461c56cf4896f18bddaa66c3beec7b909fc8fb9.camel@intel.com> <0a6c90d6-f790-4036-a364-d4761fdd0e95@sirena.org.uk> <21d7e814-8608-40ce-b5d3-401f2110ad91@sirena.org.uk> <55c629cc-0545-460b-91cb-2ebdb8ae9051@sirena.org.uk> <7d03be1277a5f4be23df35ca96f4d6cd77735e2b.camel@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QS3kL7vV2OH5bUkc" Content-Disposition: inline In-Reply-To: <7d03be1277a5f4be23df35ca96f4d6cd77735e2b.camel@intel.com> X-Cookie: Humpty Dumpty was pushed. X-Rspamd-Queue-Id: A737F14000D X-Rspam-User: X-Stat-Signature: tyfd3cn61o7oebkgjomoeicikabyi1g7 X-Rspamd-Server: rspam01 X-HE-Tag: 1690993675-405370 X-HE-Meta: U2FsdGVkX1/g9EQM5622KtZehu9BuelRxVXkN1rbaiJU3QMr3JU3yYd3jH//A+SWxZphZMpE0uPJWorJlOS7pd89iG/GZ9ecWgD4D7wATeMiXK6miRO5RNvqSG321u08hhLghpDLNNC0/KlPlSkl6bSHXruQyaaDYSnG2D2uJIDgZ2j3lANWPgfQYohpGf5bIsOWCJr9DLFskFcBCoRmGvSD2zvX0ZOcRrzDTTFtfnetBg7XqVuZ9yQEGWpy3SL4vxSKoFrZwuvjggu0/A03clinOHf8YPEbOim0SFh3Nwm7eDtHuLorr7y6JOpCnKHpGY9ikQZsGnZw+iGbbFP2eHzJ/Xww0C642sjDX5dP1wTaZqn4SgvXtQM15rHPs9rzQLhg6mhf2QF3EaiErA5pXvm4WytUIOumIEWr4on5bGN98VMgIDDXAvkZCXbxppDmqeoEyxx47YkAtVhnRSbBU0WPHf0LLDxkcEvc95wvPnvsv1ki9/J2TAyfZdiFgCqtmDYmFS92mNrIBB+pQp9wmGSu6Tau7SF0bSis7uZfOoPkYEMNvMdSVhtnX4gBpJx7JfmtC0OEKcVurYyF9LPhsqOQQXXexeIZgynRdtuncGS5WUa4PxvcjB6o81cb8bUnAO24s5elkGcGn/vig6EyqQ9tKukJqK1/iy2ikvFpPqhZ9YaAVlPsFESPxjYcuJpz+coVESM381fzR9tGNj+kof7wskF4K6FFQZ7fG0kaT+1MMUUgmDRtQsrcdEZukCni5d3NbactSgZqHLmu8caBTpchSXNxwQbYkIdznshIG8DqJGqbkZ1dCcRFJ0MfGPNS6KSAKscfk46i1wYrdjKer8T1PqDE7wHSBW2Nh23ARbW5jwPHeZhpnP5Q+0glBu/B6oFU70tiGEIwqAZ4YYb27YuOdIAoIhFaXY9ZMA5ULqC7f653WFJDV6Qp9M8tC6njZDdASJedrEGYWoJHtcS 2llNN3Zv 8rkPoiiUiemNvByO/PWfPedA6qNVhU24CAilqo5dzwdyRiAF04H4PNpWkk/A+Y++vFa74RSYF0U9cu5ZZ2zHlK17aq6cf+uCJMHlmZMpb+1eCem+un7MczYK5Bq5HFc+nK6ltaI23ESgBjyPEwMZh8jn0GgPL6CyCK8gRAxcKDeCx3ykhsZY+AbKpDU+a35OLGADOcjLM+tbLxVfcUrhRZQnTjBsAJ11lyUaGBuUHhQs4l1mcF4Cg7HTIigQp6gqehohP5ak4ZT4KKdulahtRt++f/37tMBpHmJUVLNOmNFmM+sDjYTeEUV4Aw5z/HURAh94NOB6Fpyv9aIeSow0pA+0sTsf0atcTc4+OA/RsoY3hlG8dU3oX8GmyCBLKjrPm4p51PhRA0CLtK9kCtopMC4KSooK1QEcowl6k9aOejA72YH8Ki0WZz5/U9NTRlYSi7jcHvKZWxDqamLECAmufC8zezm0wXw3ndlcYyybDyv4h1d93cG7CSQjMUH6WWHRCxcMI 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: --QS3kL7vV2OH5bUkc Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 01, 2023 at 08:57:59PM +0000, Edgecombe, Rick P wrote: > On Tue, 2023-08-01 at 18:57 +0100, Mark Brown wrote: > > Sure, though if we're going to the trouble of checking for the flag > > we > > probably may as well implement it.=A0 I guess x86 is locked in at this > > point by existing userspace.=A0 I guess I'll implement it assuming > > nobody > > from userspace complains, it's trivial for a kernel. > To make sure we are on the same page: What I'm saying is say we do > something like add another flag SHADOW_STACK_SET_MARKER that means add > a marker at the end (making the token off by one frame). Then you can > just reject any flags !=3D (SHADOW_STACK_SET_MARKER | > SHADOW_STACK_SET_TOKEN) value, and leave the rest of the code as is. So > not really implementing anything new.=A0 > Then x86 could use the same flag meanings if/when it implements end > markers. If it doesn't seem worth it, it's not a big deal on my end. > Just seemed that they were needlessly diverging. Yes, my understanding of the flags is the same. I'll definitely implement omitting the cap since there's an actual use case for that (extending an existing stack, it's marginally safer to not have any opportunity to pivot into the newly allocated region). --QS3kL7vV2OH5bUkc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmTKhAAACgkQJNaLcl1U h9AuNwf/eOsxbj3CCh77urZ2bbcgtkDnG2gOY0uK7lM+wipr3GCiDM6ySyjpMrSm 8tfpAV/QhsCNxV2mHJIbUdNW1v+94GUDf7fzu9+pHKrjZpAfWfo6X7KOPFiJaGgB hHeQd7CNvTJNIwSPjgjHEvjsnp39rstVvNFaonSi/9GXlnt3HSqXPr/awnfCoArZ eC+NqtyAQ3x/cc8oW9e5cvylNTjXAWg+2QNNXnVVsX6KQkbPXMI6VnQocQBHNCRo V25MLEEvRVtpXVUihvLkRuA5ILxM/k6sDHhRjaqgIHDyDIAKplJXwIjSLoMEroq3 gZY23CL6NCYvjjFyc6XZbpALl9hrUg== =/CYh -----END PGP SIGNATURE----- --QS3kL7vV2OH5bUkc--