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 9510DC04E69 for ; Tue, 1 Aug 2023 17:29:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0128E940039; Tue, 1 Aug 2023 13:29:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F04ED940010; Tue, 1 Aug 2023 13:29:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCC81940039; Tue, 1 Aug 2023 13:29:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CDB53940010 for ; Tue, 1 Aug 2023 13:29:09 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E75B340BE3 for ; Tue, 1 Aug 2023 17:29:08 +0000 (UTC) X-FDA: 81076221576.14.6D0E864 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 9A938A0005 for ; Tue, 1 Aug 2023 17:29:06 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="C2/wNB2J"; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@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=1690910946; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IJSMOT5dP6TC85UlEMOSWP1NJ0GwBPZjZkQjLwWEmkw=; b=ddUKwSfizHF+eBYO9oDvcF+uLUp1u1lc37qT3Wr+vQ/KLb8qse7RV255E3zJaIRELyM+aV Eud+VPNgAjNPhdihFNt3XjtGrD5Sn4Tgv+CWg2T5hbLUD7Kjj8s5DFCn5nE8dN7D/gtumB 7+QUz78tYG03sIM4AXp354fO0bX/ZIc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690910946; a=rsa-sha256; cv=none; b=TR459IsbHUkmcMsyc6YuoJYDwM4FDWY60ktUrykXfe6lov8E4n1vhOlkD8dFAiGbzsf1hi AO/8OljdvHO/17xkfTy8gYm5KsaHDs7ylYodD3ZGJs2Y0Pgbj3SlxsXBpPl7HfxtmO1i7J lP5DummDvQKxz7x9ODhJT3sA5hc4txE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="C2/wNB2J"; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org 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 4FE746154F; Tue, 1 Aug 2023 17:29:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24956C433C8; Tue, 1 Aug 2023 17:28:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690910944; bh=ZsqAQZoA0AwoghZtsiou8KjavxZCx4Uc9yT9Cen9PwU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=C2/wNB2JDb34xXNtBAjWvhO/GaBvzGr/zJJtBjZuERqzx5hCgYqVR2Z+yMEi1nB1g LB0Yo3/DClX0+w88XYSsol0eaOaXOk1/B5cZ1YEJEPd1m/pD4h07rixux7YzOnGQfn 73lzCbJsnMCFwfmL8CoCvaegc6szz51GwgMxu1wRjLDWAyBJkdQYbjYlQRUX/3IA9X fbdCmHDjJqIWvELjOL85wJ3Z1UgOHv2a0U/U66LVBpppf9WoEry95VllY3hGwZDVyM RFQCf2Nsp2layhGAkoAPp2zUoFiP/K4PCZefA0ZwfrOBsL0g1dIAaZskC1zvxq7AnR DqO70EKfKhTiQ== Date: Tue, 1 Aug 2023 20:28:14 +0300 From: Mike Rapoport To: "Edgecombe, Rick P" Cc: "broonie@kernel.org" , "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: <20230801172814.GD2607694@kernel.org> 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: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 9A938A0005 X-Rspam-User: X-Stat-Signature: 9wsamj85znj77u9z7xewnytcimmcsqgy X-Rspamd-Server: rspam03 X-HE-Tag: 1690910946-477015 X-HE-Meta: U2FsdGVkX1+1eaninl2CPUesO7pg9yokvgF8SAPrLOg6UyTx7J7ZgwV6CwD06Q+jOc49kdL4TagfLXo0aJQKCVIsTBLT3RrLw7QiD59hhqfSlLtsJN+n2zBBRTDS+Cs/cgprbBANEPV3j1NWqfdBGFVTetFbAc9H8HdZOMIQgQekVRz5FJXXqMC1CMpIvQZgr3kNtXFG/qTRmyIn5f+uBkegL/DRlfeCi/fAWwAc2mAzQFRdeVx7gZinOhQ4X/GJGvFpK1jfedZcIc0XhpHTVd74hoD+L68kvuT6WMVg64jke1pq+khjDCR4jl/iSdFfdORaJoqntomT0HwnPF21SStnEfuihyTRzKv+zCtyICNIQKQgKM9OwdSX9fq+rA2SAz49Mg4vKLNtIBTUin+M/Uxr6mTLNdbcFqgmzxUNQNsoARvfclNcLzzsfZBSk4zH2rxnhuYNESwJ9ySOB448gZixp2//ZUwqZI1OU/VOuxEUCnqerUTXr4hK0JPAeKEEl8uqNyC2YfBegZmcrXmQXkyo3yyFT+UkEBvkDrccE9ztv5tyIun4C08d874toFvsUZTmJh1V8qW5KTbYTkm1d6+g7gm0NfdzCZtX1E+eK1xP/ZNroWlR1Mc1M9CqSKSkir1Y85jnWS8C15MZXI7X2Kh+tCFPJOItFf1/9Oo0e1C5KlJMGaLHY+Qpc+eayjJIomJX+Tg6bnWKN3QcP7FCvBlVpdt25jd3FT6UbTob022PwM6jdZpylgDkKRzAWjWV++mZIqKPnTJoQIcwOKKlfoKf2Hk/JV84KbbYuE1tvxSV2Toxg+5QZBI9nNl5cHd7+8A6deqi4CQBAUgPSDrEG7P2PVle/e/DK7LQJQDx/0ygFfTGhq207S+zYdmajXwdx5oGro1F+xK8DO9cVvxEpR6pH57QJ+/f/Ezhbl+o+fRO1Dg0VS53Wb1OGs353qoUSR9xhIWUmSTElL/Z6yb gmsOV0Y/ YwZGDZxYjnz1JAA9r0jtqIkMxfycNPoSXzedIvMJQUFwkndu+q++uanaHR3QS0cDLCE3OkEaDn3tRpP48vPbjongdxSz03UmVOMW7I2dffNRqdCmKgvY4H2Vp0hlS0dXK6G4KotXbS0nUzaRB7jmYM/VjfEAW8I/DioSxBSH0KPZOR1CeFMiWn1EboLyECOO2Mrs+1mFTzMSQr9BNHbb2sV0yHNb/T7KLMnpCYoZM0Xzv+dKhrHpgCwrIUrZ3yYm5aDWpORp2OnpZL/x+OcZCbGQnGqhfQsEek6j1GSOCi0LbXhLi6LnyUf0NtNES0PbLoaWe/IftEd2b3NGI95+HS3UP08szPaAfCBl0n34piOteMTd52bvhYYpvPruL7xZeYxCcZgECfjWhf3N+LBRX2g3R0ICK9kaEGVHzfeA0r7jYHmO9KQkjGDbdKxm956VpCOrAIl/MsuuFCCM= 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: 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: > > On Mon, Jul 31, 2023 at 11:19:34PM +0000, Edgecombe, Rick P wrote: > > > > > The thing I was trying to get at was, we have this shared syscall > > > that > > > means create shadow stack memory and prepopulate it like this flag > > > says. On x86 we optionally support SHADOW_STACK_SET_TOKEN which > > > means > > > put a token right at the end of size. So maybe arm should have a > > > different flag value that includes putting the marker and then the > > > token, and x86 could match it someday if we get markers too. > > > > Oh, I see.  My mental model was that this was controlling the whole > > thing we put at the top rather than treating the terminator and the > > cap > > separately. > > > > > 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.  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...) > > > > > 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==0 does in this patch, > right? > > 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. > > So the question is not what mode should arm support, but should we have > the flags match between x86 and ARM? What if the flag will be called, say, SHADOW_STACK_DEFAULT_INIT? Then each arch can push whatever it likes to and from the userspace perspective the shadow stack will have some basic init state, no matter what architecture it is. > >   I'm not sure that's a > > particularly big deal though. > > Yea, it's not a big problem either way. -- Sincerely yours, Mike.