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 319B6C52D7C for ; Thu, 15 Aug 2024 13:37:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCF986B00F2; Thu, 15 Aug 2024 09:37:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B57D66B00F4; Thu, 15 Aug 2024 09:37:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D2F86B00F5; Thu, 15 Aug 2024 09:37:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7B1CD6B00F2 for ; Thu, 15 Aug 2024 09:37:36 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id ED6C4416DF for ; Thu, 15 Aug 2024 13:37:35 +0000 (UTC) X-FDA: 82454582070.30.E43AC4C Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id EDDE8180005 for ; Thu, 15 Aug 2024 13:37:33 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.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=1723728981; 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=EjyBwCCH5TdAX2QukKQmolJHNz2KFaA0gvsOWOk2dlY=; b=tS65Hz3lswQsSIGGSOL5yQxdKhAFvOKjagRq4er7rDABQgzhLhUOB0fsxcYhc8KA3DUYKl kJY/VU6z9obXC+JGDRNvVS0yrqVBq9L6KRsOHTyoihvDXCdsYGYaMmB/OA9yMxFtqM8xrF DFGG4MkTB+xdrUsy8R6wx9upOwJMLsw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723728981; a=rsa-sha256; cv=none; b=QV/b9HHRE9UFY4sGeuyAbgdasdrXwKK4p/RR7FSB2aRQfG5MbAtOjKYN2yDlm4seWsnE2g ouBSvt1UmYYYC//LrYIla/+wD62u1mSyntD0GLlUzlfisykox+AmO0lQF4KT1lMRnAXf0P oZENq5UI8zSKN/xixLncwg205v9ex+U= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.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 D46EC14BF; Thu, 15 Aug 2024 06:37:58 -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 3AA023F6A8; Thu, 15 Aug 2024 06:37:28 -0700 (PDT) Date: Thu, 15 Aug 2024 14:37:22 +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 23/40] arm64/signal: Set up and restore the GCS context for signal handlers Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-23-699e2bd2190b@kernel.org> <08932f6d-01ef-40e8-97d2-08f0d2016191@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08932f6d-01ef-40e8-97d2-08f0d2016191@sirena.org.uk> X-Stat-Signature: h5od1xjsxyzk5chzpixmnojr7c7jwb3d X-Rspamd-Queue-Id: EDDE8180005 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723729053-350570 X-HE-Meta: U2FsdGVkX1/kjZi8Qqlb/ol6KaIHM9aNG+9jKrUwE5+4A7+uPbf2d97EsOcThSNJkAdXbxL3TEmt7f5kUbGidLJVoiZM773H0GFBe7aNP0QimFpR/xe7+jt2LQYYkGBiVCVC/BREBBU5S2XzC6cqbG9Ev8NpbQM6ehC4UNJeP3y7vCAUezk/Znuqql57eAv+L2HbwPmIYLJlma9VnDla5qZrmTj2yLdVGtqU9TW5R/4gjONCqAs5cRvJdWWnAJ/xvQM822JqII1L//5hSbeZQWSMV41mxs91Dvf/7Tn09xQuxMayhWbgHJ3bmHf0i2PEkCpXSBcC/m47Oy2njNaytu5JG7/YUdTo6thFwRVMyU9sj45j05UKWHmfgV8CFqWlTNhdodLrMdC/4SDV7TyF6DmZJokzH1Q4YjngnKCcnjVAM9IO+qcvlGfX07I+vuSw+VDFbCEqMjpNyYneUME25Mx/qzNX3hIY6n9IhcZZ3DprL7sWPuvGC2Drn+L5JdbJkyAZWVoUs/fcO44BHiqsVMOEXOHjg64Sj3bu1jzqlPh2cDkqTvheVf0FhhabLOFMrFjCJZp2hyhOicpmOZ/caBkwnGOAqfnFOFm1fp6iCQKzcNIY3+n39aqnzNvm5endK7wYj/DNoHpyec11R7uXaBXuvvtZ2aboa9aAOaPUBl+mB5Nw9yAKtOV7FU3hYE1lMK32PkGv7uWosm4j09vpSk+FkVwWvnsf0lrkuPybML24QxyOhzXlqbe5WXVozvCn9lHwKi2d7lwqzabB8kj1PgyyBhoYt7cDE2EoUhk+KsdtUbxPHS7eAWASKSL1bDo17K7EkfJ+ybrtYD7FnosDEpPGTLr95hgGjdHDiDHE58/FiskGaVXNNczhY8CtwASg+Y4oz2Kc24/4OzcqzFYbiwt5DM3hT9Ib6bYxtskcT9dE40v0svPzYuB8DyPnTX/BgGH7L5Zh8hcxNZ4vwj9 Ap3/88wT PRny2JcbGxONoq7ZPXEy3TfrcrB0jnnxOp8P2CWPQ7lULTnVY1GmQsN5YMahjsQB4O9rB+phsg1HsX0JGZAUBDGY0huihocvXBd+nM8mFVvZ7H0pftysMu7YOLVUbAQsOvOuNzXanzDejoWXrtL34tHDuReOSnhhiZl9P43KSl0Sso+sdmQrT5+Q8DuHO6pvJbCVi0Fl7FmaWPccqisLDmaYZyg== 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:00:23PM +0100, Mark Brown wrote: > On Wed, Aug 14, 2024 at 03:51:42PM +0100, Dave Martin wrote: > > On Thu, Aug 01, 2024 at 01:06:50PM +0100, Mark Brown wrote: > > > > + put_user_gcs((unsigned long)sigtramp, gcspr_el0 - 2, &ret); > > > + put_user_gcs(GCS_SIGNAL_CAP(gcspr_el0 - 1), gcspr_el0 - 1, &ret); > > > + if (ret != 0) > > > + return ret; > > > What happens if we went wrong here, or if the signal we are delivering > > was caused by a GCS overrun or bad GCSPR_EL0 in the first place? > > > It feels like a program has no way to rescue itself from excessive > > recursion in some thread. Is there something equivalent to > > sigaltstack()? > > > Or is the shadow stack always supposed to be big enough to cope with > > recursion that exhausts the main stack and alternate signal stack (and > > if so, how is this ensured)? > > There's no sigaltstack() for GCS, this is also the ABI with the existing > shadow stack on x86 and should be addressed in a cross architecture > fashion. There have been some discussions about providing a shadow alt > stack but they've generally been circular and inconclusive, there were a > bunch of tradeoffs for corner cases and nobody had a clear sense as to > what a good solution should be. It was a bit unclear that actively > doing anything was worthwhile. The issues were IIRC around unwinders > and disjoint shadow stacks, compatibility with non-shadow stacks and > behaviour when we overflow the shadow stack. I think there were also > some applications trying to be very clever with alt stacks that needed > to be interacted with and complicated everything but I could be > misremembering there. > > Practically speaking since we're only storing return addresses the > default GCS should be extremely large so it's unlikely to come up > without first encountering and handling issues on the normal stack. > Users allocating their own shadow stacks should be careful. This isn't > really satisfying but is probably fine in practice, there's certainly > not been any pressure yet from the existing x86 deployments (though at > present nobody can explicitly select their own shadow stack size, > perhaps it'll become more of an issue when the clone3() stuff is in). Ack, if this is a known limitation then I guess it makes sense just to follow other arches. I see that we default the shadow stack size to half the main stack size, which should indeed count as "huge". I guess this makes shadow stack overrun unlikely at least (at least, not before the main stack overruns). Hopping to an alternate (main) stack while continuing to push on the same shadow stack doesn't sound broken in principle. Is there a test for taking and returning from a signal on an alternate (main) stack, when a shadow stack is in use? Sounds like something that would be good to check if not. Cheers ---Dave