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 B919CC04A94 for ; Tue, 1 Aug 2023 17:57:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F9BA940048; Tue, 1 Aug 2023 13:57:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38296940010; Tue, 1 Aug 2023 13:57:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FCA4940048; Tue, 1 Aug 2023 13:57:23 -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 12016940010 for ; Tue, 1 Aug 2023 13:57:23 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C6A03A0B4C for ; Tue, 1 Aug 2023 17:57:22 +0000 (UTC) X-FDA: 81076292724.29.7F47CA3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id B8708100012 for ; Tue, 1 Aug 2023 17:57:20 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JZJMaAT4; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf05.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=1690912641; 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=BnvU0KbW34ZEggtd8GRNYFljWI65vc6zfYelD0RpVVg=; b=kaZHmoSci3MsOtVg1flc4yxavfeRMhgvW7B8DWBGeVPp4q2Vm9Loj1KRRYlvWIGW7tQfVS AMxqu6Sn2itgJSAPqshesEcoiSKxSBy3UGqDFQo+Y6ySzel6BybpLbU+NW+hpUVTcKdEVT Wl/G6x1tcbf4NGdktgMvdHKqktKK8J0= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JZJMaAT4; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf05.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=1690912641; a=rsa-sha256; cv=none; b=Y+q1q057K5pxgEwHhzuWGSmwxs57rj2G1Jbtg54r1Ay6P09xL1CkQyfWB/9UPKIQ09CYFi nA/9oFEET6e8mgRH/rQRbi98MXNBCFdMV5nhYktDFSiQ77sQNOC0rXabqDyzBQgVvHPcpr Rt3CZGKUpIp4JueG5ONryYRQU3JRQUc= 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 879EC6165A; Tue, 1 Aug 2023 17:57:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A047AC433C8; Tue, 1 Aug 2023 17:57:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690912639; bh=F8CAARuNUeaGEa3yA1waQoVFs2zc6rvh3zubyIWd+RI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JZJMaAT42SQFAM85RnUbpnm4my8uLLOgrzrpv9ey5F7iOsTiCZBEwwsQMLRUS80/H gICFBbZERF2JfuNbCyCasY1N2jUMSPr8iIihwDf950iYsquKfhXkKiL5b+msCXfHuc B0hu58CMAQA41AZ35HEN4GzCtnJS9SRnAzeUVfmqmxuG8PriXB+8iNnYQ9IBFlhh0g 5LHahWPZHyPVmmgOLHdeR6Ip9wxGlCVC4KZ6u6/MqfCxXMrpYZItw3hBiaTqg1xfTN tUOKRiTjydZGF6wuuwu94EdSvPU1tYZYsAoggPLjahr6Dr1QtlFVqW2D4lr8QT0Spn skZg6nLYjJM5w== Date: Tue, 1 Aug 2023 18:57:08 +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" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "hjl.tools@gmail.com" , "paul.walmsley@sifive.com" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "oleg@redhat.com" , "arnd@arndb.de" , "ebiederm@xmission.com" , "will@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" , "palmer@dabbelt.com" Subject: Re: [PATCH v3 21/36] arm64/mm: Implement map_shadow_stack() Message-ID: <55c629cc-0545-460b-91cb-2ebdb8ae9051@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WYhsHyqynSPadbUB" Content-Disposition: inline In-Reply-To: X-Cookie: I thought YOU silenced the guard! X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B8708100012 X-Stat-Signature: fmpip7scjkemss6zqxopbdibhdhxwa11 X-HE-Tag: 1690912640-699897 X-HE-Meta: U2FsdGVkX1+W2Js/NyBxmIpGfeCWQo1drURJ5VdbIhEr8EraALQFfRt36XrkIOKQZ+LJ8X//uLOdvlgZAojic6mVg0NX8b3jvO0mf61431BXHbEz07ti9vBO9FoPcKkHKO115xm8UuuppXzyL9C73ieblhrC8XwjHXrT6tQ9Qzzz4huJ8NRH0ZUs5tg4Qb6YlC8pYec25aG8ILW5G09YejzdzZMBL+2/TB/BjbHw/Sp8JRlNe6hAjXtpL/Ov/l9S/dmZouydRtptq9jK9BzQ1AOG9Qc6CHfsq4zILrzHSGTe+eTcn0bSYoC7dFN4VQJ8zYlcXdsEFWeVE9EUpFO070YqEgYlFxphb6mkqKPlLlPxhda4kn3/ydD0jFfS75oMJBSgahAiU+TD1m/+MvvfG9q6IZqx4RLvOKNlCtwChtwUfje4FnWHUKsh2QDHpak16U3QFK6aPk6fFUvK2Vgmnai1l0KyMnjuGi/sPJv3Sr9z4vwdLQjrtQBnBKArlZCRnakA7/n5lIWY7Fx6wpj/fpYZl08fR11uBrQWxJJFCX7XT4eTVL/H2RPYXYsJAQMEZldPIqqt+Cxe67dr0vH14DvD0r7bR4EKH8lSeZjvglHiAXC2fYkiQLqAcmE9xkwd9LkHxP2WqH1de1pD8QCc7+7duLtd6p63W8IhilZgEqxilPE6x23/3YlU8Y1GiUqBhzz6lynI+t6VfozB63sb2zsohL/176OQQ5sghPYlVIvRk1VQbFNALwgA2mMKdnYrDevmriv6cWEeR6k81TzJQjqpsB1EuCGMrU5xHktgSE6yfm3RWK2EQ31r3GRJZXTQis9bU0YCPZIbzhL5/5mefOLNfgtOgecUYqbVok8lcjzxfwXPbgfhbS3NcvYmBa8/JRTDbUj5+pkmAPGKf3pC4iebogeqgnbPjl3v7UHL98yPxKgQan5tsjNNoh09bewEQCmjeSaj8bQqW1JJJ/f pktH7F15 1KAiLi5EdKSVWbSBm366O+n/VkDRtzwm+1NDLK4ofNhwPd6h5jCyuJaHAX/I5ht0RRKc+/zIta3nBV4wnc4UGMn1cV8M2L5v6HZfSzneA/3cuPSrAgekaKNwCbGzAVA6zLIEboDQbRba191MIt6kRezjeNGFHEdGQCljq9XKpA9ehwBPhvTjJ0RbO5dN57sHXP6pnQwtGBwrRA32Pz9KqZWDrTpTIBgohOcEjh3zpilzHJurHEvjVvzJ1aGum7506ZSYcd4Kvm1VLrUIJAHpcSsmPvvFmw+G0llrHLhrrXHBmEGxJSWA6KKNHUgMJC8nC7C8L43OX6HpquhvH8xIhRZNG68DQwoyJCpNOw405HrjwLPzRbny90Q8pJgMQ3csG5DeFzhqqFfJfYng66FN0RPSEawS2FomCkfa55bvNw01m4vuQqiYX/V44g63ASsBRYmyQBywvcEiWmMlRf5ldug18wz0KQL/WXn0tFuTY8/3+LMk4qcTk3PGzqden/hebPjCP 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: --WYhsHyqynSPadbUB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 01, 2023 at 05:07:00PM +0000, Edgecombe, Rick P wrote: > On Tue, 2023-08-01 at 15:01 +0100, Mark Brown wrote: > > > It could be a different flag, like SHADOW_STACK_SET_TOKEN_MARKER, > > > or it > > > could be SHADOW_STACK_SET_MARKER, and callers could pass > > > (SHADOW_STACK_SET_TOKEN | SHADOW_STACK_SET_MARKER) to get what you > > > have > > > implemented here. What do you think? > > For arm64 code this would mean that it would be possible (and fairly > > easy) to create stacks which don't have a termination record which > > would > > make life harder for unwinders to rely on.=A0 I don't think this is > > insurmountable, creating manually shouldn't be the standard and it'll > > already be an issue on x86 anyway. > If you are going to support optionally writing to shadow stacks (which > x86 needed for CRIU, and also seems like a nice thing for several other > reasons), you are already at that point. Can't you also do a bunch of > gcspopm's to the top of the GCS stack, and have no marker to hit before > the end of the stack? (maybe not in GCS, I don't know...) It's definitely possible to use writes or pops to achive the same effect, it's just that it's less likely to be something that happens through simple oversight than missing a flag off the initial map call would be. > > The other minor issue is that the current arm64 marker is all bits 0 > > so by itself for arm64 _MARKER would have no perceptible impact, it > > would only serve to push the token down a slot in the stack (I'm > > guessing that's the intended meaning?). > Pushing the token down a frame is what flags=3D=3D0 does in this patch, > right? Yes, exactly - if we make the top of stack record optional then if that flag is omitted we'd not do that. > You don't have to support all the flags actually, you could just > support the one mode you already have and reject all other > combinations... Then it matches between arch's, and you still have the > guaranteed-ish end marker. Sure, though if we're going to the trouble of checking for the flag we probably may as well implement it. I guess x86 is locked in at this point by existing userspace. I guess I'll implement it assuming nobody =66rom userspace complains, it's trivial for a kernel. > So the question is not what mode should arm support, but should we have > the flags match between x86 and ARM? The flags should definitely match, no disagreement there. --WYhsHyqynSPadbUB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmTJR3QACgkQJNaLcl1U h9D+HQf/dMO4oPMfSYgpJfSkqjyeMhvngNszJ/vg3XKaq4EJAEMgOh+p9YWNYPyv uBQnGou+Mr2N+ymg2pLC4+WNybCoXsyaVeF/84elK+awSuCxD9GhjtrjqnteBAWg Cjy3FqvlmXwV2AHcXeYANCjGN6BJhmbUKcJp+jwyEU+PNxMrGY4Fyos1o7DlgcDo udN5QQnR8fZ4Xjyv5ZcHWeUX0e5TsB+1e9MK8AOIRkpI52cfHU8u/HSNfOHs5an7 Ugb2wl/4tUWdslzaD4LLg+znjSCYjZ2c0uuIuigxAeFfSDhsFG9C2CiIEaa13iCj rrMq656MkRtw4gwfJ7HGsycFpraatg== =HHRV -----END PGP SIGNATURE----- --WYhsHyqynSPadbUB--