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 2B7A6C3DA4A for ; Wed, 14 Aug 2024 14:51:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB5BA6B007B; Wed, 14 Aug 2024 10:51:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3E786B0082; Wed, 14 Aug 2024 10:51:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B8C16B0083; Wed, 14 Aug 2024 10:51:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 69B3A6B007B for ; Wed, 14 Aug 2024 10:51:52 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 06402160FF1 for ; Wed, 14 Aug 2024 14:51:52 +0000 (UTC) X-FDA: 82451140464.19.6D58335 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf03.hostedemail.com (Postfix) with ESMTP id DA67820020 for ; Wed, 14 Aug 2024 14:51:49 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.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=1723647015; 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=s+dbtym/B9sg3mlNMg5hX504N7mmVLVp+RNOZ29KaNY=; b=7RdnuYIsrhxsoRBtIH38H2HzEACYU/jLxcUtvi50JoGMcSdq7y3q19dSxA2Hv5Q/yOpJRV +avccd/FIE6ebD6te9vEdLmeYNW/w0mlvrpQ5W4RQxSdgaKkiwwxuMUvtNUvruHXb+6m+1 g8/T+Np0A/ul1xOVtCg7p8jPj7zrXQc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723647015; a=rsa-sha256; cv=none; b=dHLQkH/6Ex8vTc0/kH+x0eaer28LwiRNoLtJmC/h+Q1r3s9Bbhc+4Hd+r+dV1rerLtjYJL iT64ZEe2nHdMUG2Q/uMQQUX1uXEOjK4JXbSCbGeNPcIcSajIJPj856rstUoAY8PwJ7bx+Q t7GRKR/sCq0HNBB59q4/RRHBOjCuk/s= 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 C4071DA7; Wed, 14 Aug 2024 07:52:14 -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 E6CB73F58B; Wed, 14 Aug 2024 07:51:44 -0700 (PDT) Date: Wed, 14 Aug 2024 15:51:42 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240801-arm64-gcs-v10-23-699e2bd2190b@kernel.org> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DA67820020 X-Stat-Signature: 8padyg1x9tix1kn173zrbxhdzizk66c6 X-Rspam-User: X-HE-Tag: 1723647109-865209 X-HE-Meta: U2FsdGVkX187rNccbwNXwGGZR3OVj3K0ZjNA57ugcJ3BhCaChIRzif6FE5CEKjZT2OIgPimDfKoFovjpQTSMmNF7qdhnO8XWwlGoN4m6sFAS/TeB1kidvXRg58b0Qzce7OP7lIHKqQhLlq5GI9llKWFpl9w9dtPmODowy1CTDJlT/8t3kP0Dl4X83k60OfDJImvJqrNLZW3kZmNWU0s2mJ5BW0BJHXTERJErxU7Ejh+7ggHondg7xT88YFrCk8nbWTeT8/0tp57hJC1ebPavYFZ/sr1bYknbRz0vtmX7jT4gAgwFeCLc7UPvqDKysiyPsiDIOgU17dOwCc0cCqGJ7VsGm5zsZMmdsE8QJkVJCLUC2TlAupAmCTD+paSuXHkm7lif5eUPx3jDokLBtieXXE7ErQ3hzkEhcBPjnzUA9DYEjS1rlbBSr0k1ucAnkNTIsxxjdXqqflI/4CBgxXB3yOzunWAhJ96ECvjGopEiuTJnyZSOGXDHd9B65nJq42AQPJQdset2JfFbNVYTHQIpFB6wAPnXdmsVZCaH4IYlOzLKbpvaD//m8As6xo80OBErFMRo5vG9EdzvAOjXQ5NB873WXRaTuVTiHOAhU94x2udozV9eQgTT2BxBQpGOQGFjEFmrL1aAQIIb2K8wwkOSHhMHBrgW/sugMCiopGYCMTTsX+TC/QCe4rKmywrNgy8vVk/peg56Gf2WpFp3VgTFJnCDOQO1XzSismm7lxxgHbWUDNVo9NERbhjMEH9CFrvsZ+lZrBOCNKVh1jCuTFtGlHiIB0SO1mDiV9l/b6kWm0/xqXgd1B5MoZ5u/jFTWhz8RQ42+owlJR8aYorALSPrqv7HbFeAoZuY+zl+OmSmsm0XhX74jQzM7gmsz3THxs7yuRKOFapmOblbYOiYk60jgmZjCjbK3XJsn7FUkbHxPqDp0OgvJtBlPY5yhCsM2jAO5UMKPrr9EL2583K5FPa eOwrMmyp x4cGfFItfyrPdWr4zznGunpPOoyPvjs6jIE5KoXAGSSyjO4aOIfxLppmAsifa8FfSwavFs9lHy+EopQfQj9IDoMuWxfsAf5Ut07EOvPudKwZB85iD/ijwYjHRnlD7v5R+A+xeGQGbJuCQVA8zIOaRbh6T5ukpyrEF8DTIZqT3beSM7xpcB3+s2z8HmOYBIBg7/Uvxpxz/86Fd3SUQ2tbvnYB7f0WMY/LEFhzQgaMOQmA4HAUEr1USfqKV6pVaQzLAskmersqk60YGtgTMJ5QKpyheheMLtA/NhAll8IWwr7vfuGi8ADTfQlHbfgtOefKYpfq3jOuJPDMPQFc+y0rJQmPjpg== 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 Thu, Aug 01, 2024 at 01:06:50PM +0100, Mark Brown wrote: > When invoking a signal handler we use the GCS configuration and stack > for the current thread. > > Since we implement signal return by calling the signal handler with a > return address set up pointing to a trampoline in the vDSO we need to > also configure any active GCS for this by pushing a frame for the > trampoline onto the GCS. If we do not do this then signal return will > generate a GCS protection fault. > > In order to guard against attempts to bypass GCS protections via signal > return we only allow returning with GCSPR_EL0 pointing to an address > where it was previously preempted by a signal. We do this by pushing a > cap onto the GCS, this takes the form of an architectural GCS cap token > with the top bit set and token type of 0 which we add on signal entry > and validate and pop off on signal return. The combination of the top > bit being set and the token type mean that this can't be interpreted as > a valid token or address. > > Reviewed-by: Thiago Jung Bauermann > Signed-off-by: Mark Brown > --- > arch/arm64/include/asm/gcs.h | 1 + > arch/arm64/kernel/signal.c | 134 +++++++++++++++++++++++++++++++++++++++++-- > arch/arm64/mm/gcs.c | 1 + > 3 files changed, 131 insertions(+), 5 deletions(-) > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c [...] > +#ifdef CONFIG_ARM64_GCS > + > +static int gcs_signal_entry(__sigrestore_t sigtramp, struct ksignal *ksig) > +{ > + unsigned long __user *gcspr_el0; > + int ret = 0; > + > + if (!system_supports_gcs()) > + return 0; > + > + if (!task_gcs_el0_enabled(current)) > + return 0; > + > + /* > + * We are entering a signal handler, current register state is > + * active. > + */ > + gcspr_el0 = (unsigned long __user *)read_sysreg_s(SYS_GCSPR_EL0); > + > + /* > + * Push a cap and the GCS entry for the trampoline onto the GCS. > + */ > + 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)? > + > + gcsb_dsync(); > + > + gcspr_el0 -= 2; > + write_sysreg_s((unsigned long)gcspr_el0, SYS_GCSPR_EL0); > + > + return 0; > +} [...] Cheers ---Dave