From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 8BB842C55A for ; Wed, 21 Feb 2024 15:55:50 +0100 (CET) Received: (qmail 3724 invoked by uid 550); 21 Feb 2024 14:52:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 10183 invoked from network); 21 Feb 2024 13:50:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708523600; bh=2qDB6aCchFqvsRrIZrlOnBUWRusFLsK6a7t86lO4/kc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XYWFYY21ChMcDnqRafHBvRB0QxejjlT/bZHLI49dgPa5dRacaD3UN0LLMesLDhEVK FQALDj09HDwKPE6W4jj/Eh1jqbUH+H+QnFzr8lEIlZA/imkC3dRk/JOQvq/V/1qmnf AKtPOLPebGuFFRe5xPIXDbSmUtlL944IsVvIA7rGpLNSg/1AcaSk659q46C8HRHywn bhl8FLesEaZJjbv9GARHL60svpyiaFNTpyRdOuK9i5QgdctkDvVHFN/fMwhmSVZRSB /NtzQjotaqwXeqdsZ0ePVwa6GV0m+bjLd5HQ/Rwg6sMIIZRNIfrgzJfc4uR31QEOgk nbyq6X4Uq/GjQ== Date: Wed, 21 Feb 2024 13:53:10 +0000 From: Mark Brown To: "dalias@libc.org" Cc: "Edgecombe, Rick P" , "linux-arch@vger.kernel.org" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "musl@lists.openwall.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "james.morse@arm.com" , "ebiederm@xmission.com" , "will@kernel.org" , "brauner@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "thiago.bauermann@linaro.org" , "akpm@linux-foundation.org" , "sorear@fastmail.com" , "linux-doc@vger.kernel.org" Message-ID: References: <20240203-arm64-gcs-v8-0-c9fec77673ef@kernel.org> <22a53b78-10d7-4a5a-a01e-b2f3a8c22e94@app.fastmail.com> <4c7bdf8fde9cc45174f10b9221fa58ffb450b755.camel@intel.com> <20240220185714.GO4163@brightrain.aerifal.cx> <9fc9c45ff6e14df80ad023e66ff7a978bd4ec91c.camel@intel.com> <20240220235415.GP4163@brightrain.aerifal.cx> <20240221012736.GQ4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cNQgfjDz+IAKI+aZ" Content-Disposition: inline In-Reply-To: <20240221012736.GQ4163@brightrain.aerifal.cx> X-Cookie: The second best policy is dishonesty. Subject: Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace --cNQgfjDz+IAKI+aZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 20, 2024 at 08:27:37PM -0500, dalias@libc.org wrote: > On Wed, Feb 21, 2024 at 12:35:48AM +0000, Edgecombe, Rick P wrote: > > (INCSSP, RSTORSSP, etc). These are a collection of instructions that > > allow limited control of the SSP. When shadow stack gets disabled, > > these suddenly turn into #UD generating instructions. So any other > > threads executing those instructions when shadow stack got disabled > > would be in for a nasty surprise. > This is the kernel's problem if that's happening. It should be > trapping these and returning immediately like a NOP if shadow stack > has been disabled, not generating SIGILL. I'm not sure that's going to work out well, all it takes is some code that's looking at the shadow stack and expecting something to happen as a result of the instructions it's executing and we run into trouble. A lot of things won't notice and will just happily carry on but I expect there are going to be things that care. We also end up with an additional state for threads that have had shadow stacks transparently disabled, that's managable but still. > > > The place where it's really needed to be able to allocate the shadow > > > stack synchronously under userspace control, in order to harden > > > normal > > > applications that aren't doing funny things, is in pthread_create > > > without a caller-provided stack. > > Yea most apps don't do anything too tricky. Mostly shadow stack "just > > works". But it's no excuse to just crash for the others. > One thing to note here is that, to enable this, we're going to need > some way to detect "new enough kernel that shadow stack semantics are > all right". If there are kernels that have shadow stack support but > with problems that make it unsafe to use (this sounds like the case), > we can't turn it on without a way to avoid trying to use it on those. If we have this automatic conversion of pages to shadow stack then we should have an API for enabling it, userspace should be able to use the presence of that API to determine if the feature is there. --cNQgfjDz+IAKI+aZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmXWAEUACgkQJNaLcl1U h9BTcAf+MujJo/pNOGU2neBJWmbVKrnAz60+j+uAD98t6m1YXtFChsz+YR6gQOA1 7FEah97yBTtTiSGpgeKnKCJZMVaWEYHF0Oal7bU/cO0uO6DshP7BIWygF/xyL6/r AiFhQ5IAhgRYlGKzShiXTP3rx7ITjIS/1ejalkQ4vHwCOA/N0rsnZwJadUytQjJv bHJxu0pC95Sb9lZG3yrrOqZJdljkMsnb7ThBwPRENX0XmGz/Y8l0/FjQwiyWc+Bv i4HuekjDwxdxIknpEI/kciFlk8gjthTCrAloZNN/PGNExBEppzAMUg44bTcUkuuu CReIkIoN/x1s3gztzAkcLF2nu1EF6w== =wfib -----END PGP SIGNATURE----- --cNQgfjDz+IAKI+aZ--