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 C08ACEB64DC for ; Tue, 18 Jul 2023 18:55:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F4098D0019; Tue, 18 Jul 2023 14:55:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A4368D0012; Tue, 18 Jul 2023 14:55:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16BD08D0019; Tue, 18 Jul 2023 14:55:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 07E568D0012 for ; Tue, 18 Jul 2023 14:55:11 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BDF361C8BB0 for ; Tue, 18 Jul 2023 18:55:10 +0000 (UTC) X-FDA: 81025635180.02.824552A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id D10E32001D for ; Tue, 18 Jul 2023 18:55:07 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hL9gb0hW; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.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=1689706507; 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=O63mZ8yzF6CijAtxSQoALTxAYE2vHbZSrNPF/uuCP68=; b=KZYUQz7qes9ZkD8m6bjuh4Tn2saSlZGTy/PEndwhizSdCQ6vg5zasG6gTserY+QdaZDSHU Yw/7wG/fONCd6TLS/YxWqoA6lAtNhhHsvf39Nghk6sqi3HxON4jtJyXa/+tbtj2B8MZhfo 7nVTuKm1DEMr3PLa2zjl53OJOkg+rY0= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hL9gb0hW; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.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=1689706507; a=rsa-sha256; cv=none; b=wAcfaJxegSiXlQ3N2CiunPrJGzvUq6H3IeeGRllnXjU+i8pifGA93fiYUMEt+xUGn5BWkk cXAzfdICGfr9ReuBGTXCId6iREK4VuBwdPIC0bTvO6TXcF7C4dMhFJvoFBS6Nl1UfTpHyK CAr43xvgUGCQNxvWClJ2z0FbpTYaDEg= 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 C7D9861653; Tue, 18 Jul 2023 18:55:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FFD5C433C8; Tue, 18 Jul 2023 18:55:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689706506; bh=g90tmctGip5JZ/qUltLRa3L/ha79p8Mr36vMSarsNto=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hL9gb0hWnxYQ//PahNxf6ii3EcokNDZCUKPYDDX2Uj5Y9En1S9Qey0qZDQ2RW3P2p dTTMDDmfmtisD08Vic4XKPtxlGRvJPgyq8Vz7vooyeMlS1DNpBL5LhEkFy/YxE3mnd JGZwQRVkEFMazG6MnqCTiZ62Hf2mFE7KFIDZ1yzZpMPF9iQKXY403xt9uho3pljmBz dmdQAiwMPBz8emAKbWggcfJxkiAAU719bIyF0/5kw/Nu71BoYVur9E70n5SstkziYs 8h5G21sSol6HTKBwHCSG9f3dVB8vIx3V2YTIARB0eTo6wi80Ose2YR2SPxc5OAnBn2 l/Cl4NVx1FtQA== Date: Tue, 18 Jul 2023 19:54:57 +0100 From: Mark Brown To: "Edgecombe, Rick P" Cc: "corbet@lwn.net" , "ardb@kernel.org" , "maz@kernel.org" , "shuah@kernel.org" , "Szabolcs.Nagy@arm.com" , "keescook@chromium.org" , "james.morse@arm.com" , "debug@rivosinc.com" , "akpm@linux-foundation.org" , "catalin.marinas@arm.com" , "oleg@redhat.com" , "arnd@arndb.de" , "ebiederm@xmission.com" , "will@kernel.org" , "suzuki.poulose@arm.com" , "oliver.upton@linux.dev" , "hjl.tools@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-kselftest@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "paul.walmsley@sifive.com" , "aou@eecs.berkeley.edu" , "palmer@dabbelt.com" , "linux-doc@vger.kernel.org" , "kvmarm@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , "linux-arch@vger.kernel.org" Subject: Re: [PATCH 01/35] prctl: arch-agnostic prctl for shadow stack Message-ID: <45489f30-8bb7-45f1-ad09-28de4cebf406@sirena.org.uk> References: <20230716-arm64-gcs-v1-0-bf567f93bba6@kernel.org> <20230716-arm64-gcs-v1-1-bf567f93bba6@kernel.org> <3185fa6c37e54d26d66cd0e87e74fb5492399d78.camel@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KcrOI5lcfTfmau0e" Content-Disposition: inline In-Reply-To: <3185fa6c37e54d26d66cd0e87e74fb5492399d78.camel@intel.com> X-Cookie: Nothing happens. X-Rspamd-Queue-Id: D10E32001D X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: fej1huqifwdoxng3y8sqxqknmog87zc3 X-HE-Tag: 1689706507-24964 X-HE-Meta: U2FsdGVkX1+RwagQ8tt7g/Q+0r54ZelvMOXVxUnHHbsFSAZw6bGcEZZT8zC4kVS77vNleYe2hL7K77aFOccwHpBIrdzYmYIW1/yvv3M1a5qgEgCEjymm4E6E/kXloefru2e41tatSkwSPnICJ4lVJ7rxKaA9GxFjlmb+93PN9GUXB4CWsLERYEGgX1JjhIKH5ptQxwaWjwrktuSoxuDrBxYgEUTog3cl7JTt29/eb+KtQiCeabPlg4Rm17WbD5SVgDpZBXAMD85IMbjttcqIL1lG5rhbHiWT03ggcoqfWkY0WJrz50nWFbkrJ1sNoplUpATNE9rj0umXBwG2BLjMuONjfX6TgaEr5YAj9pTcbJBRDi93B5hD4OQXVaZvL1hNhtF8WF5H9XEfj6AHbM/OdNei9qtWKRMHQqR70B0/vEkEBGI03ZzegPqJ98lWYORz1UzveK0TdgRBGSsXahxTywDHrGCMY2Kw9ORZ47B2t944EuaXxyXc6bYV0fXRUGEE3MHHf1BYnoItgXhJKKlGZ+ybSQgUPknBtC5a9Df9GBPfieV/SYtBnY6QfuxAUxWYOza5O0lJvweDI2CEfA+SnA6psIQ6iCk+RfRrSGhlkBcjQeaYnqpvPL0vnf59we+504ee+lcEpULIgf8nYJnB2Gf1kYhNPpwHRcBpTB0zIK6nSLYB/BwEG0tvrd1i2YN0i3H9VtQE5S4UGj/mRI1nfnIs457vt/ZaU90EUnAL2tRKA506LlkT0sn3Hn9pMjucvutQ/V+RYicLtk6PY3anJ8TKZ1CUfbGJOn6srg6ftZZm3FkOVMV9R49Zlo5U9ImHuik80fHu+aZAkiq0GSKmeuNIqU4sFQQ4IxVai5plc0wSK+85lT0S2H4F+Em8D7a6WEQjnd5q9wHuc+Dfko/tQuEl44IRjj7mGWhdO+qOi2ckXJfaRYeyQUG9la3xTzjUYHm52aljPYAF6pf+Yut jAGj/pnu k1XCuCtR/EBlnMHr4ycsVTtlEty8NUSt9z2komlBm4Z84RHs10lc7ueV3ewix+3dt2Cv9RhA+ExXhtQJ6M84olEaM32W/S1YdboG6ZRvwRHKGXN9CCVCZI3PBJT9UjRThLtfEyUJ/9kBZhT3RkwmCz0Pc6ozgPs3oXrelY7yChJWXyUb8clYEOpYvhwIxo9LWziC5ZBvjwSNoIoqf0EtN04nBDO9UUJlckAekxKvfh36Iuo7qYzdD65IRsvS2TAwjWxyJgQo5c0n6ZtBCPa45argdItBpBTKDqYT7ZeKe49ZVOEVku10bdk9BoPJ1qDHThWcSnoaTYXBq4DYDTrR1+5TJQV3FOZYLi/d/AKTxUoYvWCwpa7dKZRyU+2henWL2huFKyeZSqbrizlMdQG864R9TnIfkVvsTDjxAz4RPefPckfGtWF98itCsTpuQHxNI0jp+ZBlxW1js38k3yQrTsRHAPQ== 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: --KcrOI5lcfTfmau0e Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2023 at 05:45:01PM +0000, Edgecombe, Rick P wrote: > On Sun, 2023-07-16 at 22:50 +0100, Mark Brown wrote: > > Three architectures (x86, aarch64, riscv) have announced support for > > shadow stack.=A0 This patch adds arch-agnostic prtcl support to enable > > /disable/get/set status of shadow stack and forward control (landing > > pad) > > flow cfi statuses. > What is this about forward control flow? Seems to be just about shadow > stack. Sorry, that's the original commit message - the original version of this also had support for controlling landing pads but I don't need that and cut them out of the series. I forgot to update that bit of the commit message. > > [Rebased onto current kernels, renumbering to track other allocations > > =A0already upstream, dropping indirect LP, updating to pass arg to set > > =A0 by value, fix missing prototypes for weak functions and update > > title. > > =A0 -- broonie] > 1. PR_SET_SHADOW_STACK_STATUS seems like a strange name for the thing > actually doing the whole enabling of the feature which involves > allocating memory, etc. And in the future a growing array of different > things (enabling push, write, etc). I have no strong opinion on naming here. _MODE? I didn't find any discussions around this in the=20 > 2. x86 only allows one enabling/disabling operation at a time. So you > can't enable shadow stack AND WRSS with one syscall, for example. This > is to make it so it's clear which operation failed. Also, since some > features depend on others (WRSS), there would need to be some ordering > and rollback logic.=A0There was some discussion about a batch enabling > arch_prctl() that could report failures independently, but it was > deemed premature optimization. I did see that the x86 implementation required a call per flag, the logic wasn't hugely obvious there - it didn't seem super helpful. There's nothing stopping userspace turning one flag at a time if it wants to, we just don't require it. I wasn't overly concerned about the rollback logic since I was anticipating that the main complexity is the base enable and allocate, everything else would just be storing a mode. We can implement things with the one bit per call approach, I just didn't see much upside to it. Perhaps I'm missing some case though. > 3. It only allows you to lock the whole feature, and not individual > subfeatures. For things like WRSS, it came up that there might be an > elf bit, like the shadow stack one, but that works a bit different. > Instead of only enabling shadow stack when ALL DSOs support the > feature, it would want to be enabled if ANY DSOs require it. So > userspace might want to do something like lock shadow stack, but leave > WRSS unlocked in case a dlopen() call came across a WRSS-requiring DSO. We could add either a second argument with the lock or a separate lock prctl() and matching query which takes the same bitmask, being able to lock per feature does give more flexibility to userspace in how we do the locking and isn't hugely more costly to implement. My model for locking had been that there would be a final decision on what the features should be, I was modelling "can enable" as equivalent access to "is enabled" when it came to what was locked. > 4. To support CRIU, there needed to be a ptrace-only unlock feature. > The arch_prctl() has a special ptrace route to enforce that this unlock > is only coming from ptrace. Is there some way to do this with a regular > prctl()? For arm64 we need to add a regset to expose the GCS pointer anyway so the GCS mode is in there, though at the minute we prevent any changes at all via that mechanism it could be implemented later. I'm not aware of any way for prctl() to tell if it is being invoked via ptrace so that'd need to be dealt with somehow. > 5. I see in the next patch there is hinted support for write and push > as well (although I can't find the implementation in the patches, am I > missing it?). X86 has something close enough to write, but not push. > What is the idea for when the features don't exactly match? The implementation is in "arm64/gcs: Implement shadow stack prctl() interface", it just boils down to turning on or off a register bit. > I think when Deepak originally brought up this unified prctl-based > interface, it seemed far away before we could tell if it *could* be > unified. Do either of you have any thoughts on whether the above points > could be incorporated? Other than the issue with CRIU I don't see any huge difficulty. --KcrOI5lcfTfmau0e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmS24AAACgkQJNaLcl1U h9DxkQgAgZwa9pvR8VpxobsPn+zGULF2/Agz87ptksoCHAdiehLbLFMyBPdWVlPE VpUVG9yRkpPwF6CxIGr7eYT3bdZPRghlak/eJK+2vfEr9OBZrtn5jUDtLcYXHFEh 4zY9eSZj4uM6IEH8PR/edFhVsRmngGx2xU0Y4yqcmKXBT2S4OdfrOQQvQkKQ15eG oZBMN4uX+3JFgQLViUMNpPj0bbkA+G4kab1alwOZiQZfZEqH1CRuPpk4CHu51Db9 8bP7/Jy0QkCO19VmDm3NC8v3vAUoECs9iGx6GzsL41fRNlNMbEy2yyTxdz4Nu4YH /Fkhbx2eF0EG2nmwEzbQ+eAsBn/+eg== =rIz9 -----END PGP SIGNATURE----- --KcrOI5lcfTfmau0e--