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 D8497C52D7B for ; Wed, 14 Aug 2024 15:10:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47FEE6B0082; Wed, 14 Aug 2024 11:10:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42F9F6B0083; Wed, 14 Aug 2024 11:10:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F76D6B0085; Wed, 14 Aug 2024 11:10:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 12C226B0082 for ; Wed, 14 Aug 2024 11:10:03 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AF80D80FF0 for ; Wed, 14 Aug 2024 15:10:02 +0000 (UTC) X-FDA: 82451186244.30.ECC8E83 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf14.hostedemail.com (Postfix) with ESMTP id E196A100034 for ; Wed, 14 Aug 2024 15:09:59 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.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=1723648164; 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=ec16xa0MAAkJFgb/iR7aA4JVlDAS1oUwx4Z6SJfVoOo=; b=q74MAw4XCNlQsFDSTrQwrgZzJPQEpD5eocUN9REWCBg9hXI+MEH3atxYQ9a6nxPrQ+xnjm VDtfG7zfI1GqQW2G228sfW5emCEwZsyS9KmWpfcazqrkLBEnesa2tyv47NMiKWu6uTnKFu Hmx9mAwk7yrmBjxvbuH5cAPtN6b/JJ8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.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=1723648164; a=rsa-sha256; cv=none; b=lWl2wvLoe1Staw5rsw94QxVUGwy43QnIgDuoHin4m96nZ4G2j9rkuV240OmQO8uQUiYFiU XE7oV1DaFtFEfgkCCbRB7siCe8bbUDhmAvzJP9laH5CrEshi4R3esua5NF58A5iewqGF+h e/lQHBzF0T8JX2YvY6FZUANrHT9lqws= 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 A2CD2DA7; Wed, 14 Aug 2024 08:10:24 -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 126053F58B; Wed, 14 Aug 2024 08:09:53 -0700 (PDT) Date: Wed, 14 Aug 2024 16:09:51 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240801-arm64-gcs-v10-24-699e2bd2190b@kernel.org> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: E196A100034 X-Stat-Signature: sq8eax55xu4uwtkwh8nggz3gjpdo5dyu X-HE-Tag: 1723648199-164383 X-HE-Meta: U2FsdGVkX1/6ipmJt9k1Qn/ehenTazjxOZu0QwXSqaQRivG8NNpjXO16YlLeKwbK3mpsVW4DocQVeW1/NaKjGqh1gLDqjJbtpg18jLNIWkM7gjLNsu8aBsYe2eRrUUpMM5aP9ugEu3xu+fOKSWYJU2JwwaSlQyUds6scBfbFV8ATaCANF4tbW55vPfroWqPfoUDz29861bWufhB8o6cdbt2no5QEIMf6OkErCLuEsSLfYnAmKDYZRc1oFt6g4SVmyUu3eaGboszZP1kW4fKpy1x5hVMFtKLoVpgX5t1bz3I1zNekRLa64wovp9GLmZLnS8P9gAwysxXDDkOI3mQi8IeMDK95NjcAe+uaysjfi8Kw7X9vq6Y8J8Sr+LOe0/QWF0s50/DU5AJOCY21sPYpZg2tY9Ghzn0ZIrAx1W6Wazs2MaSm30VIH+OceYdO2jF23nuUoN3GNb9gIGqU1uZo8LeOhwYcMHXOzRZdHkUyo91elvbKTUaYLsxH2/85S5oXUpJ1rsqc3AcLcGnNfpqQGD+i2dv2p2GClQdcL1HDIpR8tXpzwwhqaNQ8NT+EWVPCV31rulaVYcPau6rgAfND0M1hjotFMH3yGjrbTt3qBIFIbNZGUje2pPWmdRudzj14LzBs7H0D+krGCWLq15dwBh22jpA3PlB3py4G7V3osSV2v/6EsN5NY/aeftPaBrYlT/apJk8FHk+SS+2EDRwHRIrr6E6xe9Ottpm0FfTROBwuyByWKVzGch8fO4l+52vXtKRdwnKCCWzqGBSZVh4WC5w0mU3AOPHKcJw2db8Vhi1RUCv5zD52N8v2RIOZBkviBR70c0Q0xuTUrIGL3R3upKH2Z3GSgtA1N0rdJ9uGcGtOjfFM72XnjLDX2fBURTZiW6FyTCmRCiU1J2TgpggmoIH3ie55jHswrZGNCKclwA3p88IplU3QPwU+ODn1UftYETB0UpwxjjQJ20P0kUf DiGVpGzZ I9XBiO7b1+ehIhWjwMPlIOocsdhDcXSUChbK9adrWnpJBFlN+LeDpFBS0yizTfh9vWNN+K7BwnGxWlpz4ioYn0CrrfUIODKkyjrY6R0zy3AbOQ/fV5+y4QnLVRFQ1Z4ZkNL0Tnqr8PTzDd8nZcEr+zGd/xci1s/pgXYA/6zezFbJPhQiM0Ep7fq+kc16L6TARmwjjEulB++3gwOQMBGHFeduQhjM3btp1gMJDsRevU/qPjYu5+seegI4q3myuewwZMBstVWWlxdfUWaBWzkf8MY2S5oSnm+X2bY2f2E7AN7cK8XVYGbJwv932oexqilKJjTliRph+OkXgf0eKVm++Y9Aecw== 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:51PM +0100, Mark Brown wrote: > Add a context for the GCS state and include it in the signal context when > running on a system that supports GCS. We reuse the same flags that the > prctl() uses to specify which GCS features are enabled and also provide the > current GCS pointer. > > We do not support enabling GCS via signal return, there is a conflict > between specifying GCSPR_EL0 and allocation of a new GCS and this is not > an ancticipated use case. We also enforce GCS configuration locking on > signal return. > > Reviewed-by: Thiago Jung Bauermann > Signed-off-by: Mark Brown > --- > arch/arm64/include/uapi/asm/sigcontext.h | 9 +++ > arch/arm64/kernel/signal.c | 106 +++++++++++++++++++++++++++++++ > 2 files changed, 115 insertions(+) [...] > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c [...] > @@ -999,6 +1092,13 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user, > return err; > } > > + 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. Whether a given library should break old binaries is a bit of a grey area, but I think that libraries that deliberately export stable ABIs probably shouldn't. With that in mind, does any GCS state need to be saved at all? 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? Is the guarded stack considered necessary (or at least beneficial) for backtracing, or is the regular stack sufficient? (I'm assuming that unwind tables / debug info should allow the shadow stack to be unwound anyway; rather this question is about whether software can straightforwardly find out the interrupted GCSPR_EL0 without this information... and whether it needs to.) > if (system_supports_sve() || system_supports_sme()) { > unsigned int vq = 0; > > @@ -1099,6 +1199,12 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user, > __put_user_error(current->thread.fault_code, &esr_ctx->esr, err); > } > > + if (system_supports_gcs() && err == 0 && user->gcs_offset) { > + struct gcs_context __user *gcs_ctx = > + apply_user_offset(user, user->gcs_offset); > + err |= preserve_gcs_context(gcs_ctx); > + } > + [...] Cheers ---Dave