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 324F9C3DA7F for ; Thu, 15 Aug 2024 14:01:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A33686B0103; Thu, 15 Aug 2024 10:01:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E1FC6B0104; Thu, 15 Aug 2024 10:01:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85B216B0105; Thu, 15 Aug 2024 10:01:33 -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 68E206B0103 for ; Thu, 15 Aug 2024 10:01:33 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 19857A0EF7 for ; Thu, 15 Aug 2024 14:01:33 +0000 (UTC) X-FDA: 82454642466.21.9199EE9 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf25.hostedemail.com (Postfix) with ESMTP id C8F0AA0041 for ; Thu, 15 Aug 2024 14:01:29 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723730417; 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; bh=UVmshDz/huHs92wQmEgusXjA6aDAw8Ng2ZjTzprwYFI=; b=foe23F5ucJn2S6FS/NCFrAXEumn9jw6va2lMjy+ehgumloqvRHUwbVQJERlNX8vEQNWpWE SljNjj7xqGez9OsnUSDEzbkOiHVjWtMmmIjuyAJBHIRq0TIdu/zWzAvzGdWY47niN26jRj AyvPlkwFUoZbfh6tJ6G+MRASiyFE0sU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723730417; a=rsa-sha256; cv=none; b=MCsv2SIvszjpEaxOvLu4kwJ9du7scRAYvJhqVDmEsJWk3fCMV/SkGIX285T/P0AMI1Dx2q twVSpyrty2icexBESNcElZ3JvuGHg1kD6z0IiDdWpq+SGLqEICN3gRFcZqNMtKgvCju8jl XxAuQVwMxO1Gcd+h43r5G7egmhehftw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9830414BF; Thu, 15 Aug 2024 07:01:54 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0410C3F73B; Thu, 15 Aug 2024 07:01:23 -0700 (PDT) Date: Thu, 15 Aug 2024 15:01:21 +0100 From: Dave Martin To: Mark Brown Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v10 24/40] arm64/signal: Expose GCS state in signal frames Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-24-699e2bd2190b@kernel.org> <7433e3d2-996a-45a0-b917-666a340ad109@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7433e3d2-996a-45a0-b917-666a340ad109@sirena.org.uk> X-Stat-Signature: 9skfcj6nb4hu4fogyddzux7obd1attfz X-Rspamd-Queue-Id: C8F0AA0041 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723730489-997323 X-HE-Meta: U2FsdGVkX1/48OPcrYlzCuKNRagKGDaZBfo7/qx10Fykek5iskestvl11lagafN11nn/7vReCK4pYLfy4mJa4AwTabANWYcnLoJ3DttogY0dwQE4NtDVni4gakzwR5AZChR07TsAaUXgPiKHqzwqR1CTr3VwRdj/RZxpStqoNf9p5IZOWGbPwQwHClKZ0PKpx+BJ7urWSB22llQBOUFTiYULjYoPxdC2BqDvArLDG1AA2DN1gO0w2bwaAPSyiXj968L0H1CznbW2HkrBVfQaM4rhHQZFD+KeTvc9PxtP6AZ6HbWoH/hHu06fLbjzn2jIu0/gpzJ5xSeM3MTm8Y7xCCLk2reBi7MjUm7uQUO/Wnv+ACv5Vl9dlFSAiwhbsoQbFmj+zIbdkUFU3w3IUJwF2BHy/GRX8mhlasavQb+v4cxI3JdCZKvOU32o6gYnrDNy6z2eXuwca97LHyg7viJIenznafzQz/JxvTAbqeSmTD2IIWweTVXoKM5mq1bQXeRrcYVR1sZmfK+MdDMKU8q3Y8KuEKJjsNcJYiVTAQEjNBK60NSGJ5KUU47dHri4+VR9wpcvbMVW6phe9nINlCHi8fRIs7WcrSspM48CqHQDnnJlfNVcu4TV7xwOCbFAlgUADhnuhIx6T8cfvtBWBY2AcWhtfQRFqHIFalJmZgGbarjZOYw23iyaQ/Tf4U+fmzrYsdgGx+9SYAMjgPsUMvz7JuYQoPLUvQp3NUy3kI2n/RCqTfeahl3+HZl6n90zMThlK4l1Afj1c1iuIV3WLqyvDNWZzd+kZ095T3OXxoPoTLigcrmQmxXUlE+7vNsyhrT0tzqVW9MFM8RWG3Ay99yPUv0mfYo7Gj8SS4vFgDXeoPYH6KXhFHw2XoV5VW6RG6W6PbReUDz2E8ISC3NMJ4InWD3s4VQMUGv4oG2fEGtfFztAJKNJwOcqXxnnQVmGiIUrisoX2VW9y3nH97K6gFr JCpw/gxF C2nEPFMAEl0pwIR0EtVVPZpJ6GHgJ686tI206x69e720Ei1bjXEvsPY/Rr/sJYjDQx7Ob92SK7e1wvfIRB56XyAqcRmf/KFoBmpdlzoGoj3r3NK1oAXFQHTvwf/99gjXYGpcP9DIOObcdaMEAQeN090Uuuq1mN2M8oV5nyOwJqTWR/lJ0h5uI1FFX04aRO8wR2x/hUnWPkPazGu9+cZozn/28rQ== 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: List-Subscribe: List-Unsubscribe: On Wed, Aug 14, 2024 at 05:21:44PM +0100, Mark Brown wrote: > On Wed, Aug 14, 2024 at 04:09:51PM +0100, Dave Martin wrote: > > On Thu, Aug 01, 2024 at 01:06:51PM +0100, Mark Brown wrote: > > > > + if (add_all || task_gcs_el0_enabled(current)) { > > > + err = sigframe_alloc(user, &user->gcs_offset, > > > + sizeof(struct gcs_context)); > > > + if (err) > > > + return err; > > > + } > > > Who turns on GCS? I have a concern that if libc is new enough to be > > built for GCS then the libc startup code will to turn it on, even if > > the binary stack running on top of libc is old. > > It should normally be the dynamic linker which should be looking for > annotatations in the binaries it's loading before it decides if it's > going to turn on GCS (and libc doing something similar if it's going to > dlopen() things in a process with GCS enabled). My thought was that if libc knows about shadow stacks, it is probably going to be built to use them too and so would enable shadow stack during startup to protect its own code. (Technically those would be independent decisions, but it seems a good idea to use a hardening feature if you know about and it is present.) If so, shadow stacks might always get turned on before the main program gets a look-in. Or is that not the expectation? > > > Is there any scenario where it is legitimate for the signal handler to > > change the shadow stack mode or to return with an altered GCSPR_EL0? > > If userspace can rewrite the stack pointer on return (eg, to return to a > different context as part of userspace threading) then it will need to Do we know if code that actually does that? IIUC, trying to do this is totally broken on most arches nowadays; making it work requires a reentrant C library and/or logic to defer signals around critical sections in userspace. "Real" threading makes this pretty pointless for the most part. Related question: does shadow stack work with ucontext-based coroutines? Per-context stacks need to be allocated by the program for that. > be able to also update GCSPR_EL0 to something consistent otherwise > attempting to return from the interrupted context isn't going to go > well. Changing the mode is a bit more exotic, as it is in general. > It's as much to provide information to the signal handler as anything > else. I'm not sure that we should always put information in the signal frame that the signal handler can't obtain directly. I guess it's harmless to include this, though. > > Is the guarded stack considered necessary (or at least beneficial) for > > backtracing, or is the regular stack sufficient? > > It's potentially beneficial, being less vulnerable to corruption and > simpler to parse if all you're interested in is return addresses. > Profiling in particular was mentioned, grabbing a linear block of memory > will hopefully be less overhead than chasing down the stack. The > regular stack should generally be sufficient though. I guess we can't really argue that the shadow stack pointer is redundant here though. The whole point of shadow stacks is to make things more robust... Just kicking the tyres on the question of whether we need it here, but I guess it's hard to make a good case for saying "no". Cheers ---Dave