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 0ACF4C52D7C for ; Wed, 21 Aug 2024 17:29:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D34C6B00D2; Wed, 21 Aug 2024 13:29:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8331A6B00D4; Wed, 21 Aug 2024 13:29:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AEE16B00D7; Wed, 21 Aug 2024 13:29:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 49B236B00D2 for ; Wed, 21 Aug 2024 13:29:00 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B4F501C459A for ; Wed, 21 Aug 2024 17:28:59 +0000 (UTC) X-FDA: 82476937998.20.18306BA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 0915F40008 for ; Wed, 21 Aug 2024 17:28:57 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724261257; 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=e1yWxOqcSYVK6VoeSc3838hW4upjyImxcQYEVhL7nT8=; b=nX8fd8ddWfS7f9sXeMDxPbTu3f/fCCsxhFhEF+DgWmmJgVamz/yNbkQOiIkkBdWwwB4UIU CFNjd3eDUMAR/Uz6JqvS+o2yrHRXPDjytZ0hWFyhl/RRimG7efPjgL/f9oIaQ62ECRnuNF JisyRhGk924ORxYDELaAdjz20KkdQxk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724261257; a=rsa-sha256; cv=none; b=w5MMYBOSxoON8WtkgO3bY8oixCpKQZYqfihHBn9UIHg39Ephh6kCkax95wj1ce7liTmfcy w9ibod0OS9nYqfJ6vqf0h3Mueu2mqmNvqsGJlCCIpTtXpBD2rjxLndWyfRcHIsFP0Q8Kkj QWbhfmHTC6Z0D2tp9+wDkitjr9UZoF8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id BDADC610AA; Wed, 21 Aug 2024 17:28:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 439DCC4AF09; Wed, 21 Aug 2024 17:28:51 +0000 (UTC) Date: Wed, 21 Aug 2024 18:28:49 +0100 From: Catalin Marinas To: Mark Brown Cc: 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-Stat-Signature: ftnupp8zsm3ccoirqmc4b4qpwi7tj3nd X-Rspamd-Queue-Id: 0915F40008 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724261337-522588 X-HE-Meta: U2FsdGVkX1++nNpDlRjFPZHYTJnIIRIoYzoi+gwZTrSpvn+3Pq9EP30XB3wkwPEPyBbHYYWLZmWwaFzFCbn8zaXVM4LOG5YkUF5YX0lWIT+mtVAoKl4Ez9FgNj3xV6c0kE1gd1t3JUyYRNg1CjRQ1GzEzYfwwKQ/7J8A1Kec3qSDxmQCm9uNb5Y5G0EWjGs3xRYJjf5GutMlbNykW3gGBWjHHyddXPk28n6huZWzvzVhoi+9UYbmNaJnyzqCgNbQhAUTce0T9DbmEnUmhGeIWYWUidId5gkZ5c6JGTwHqng/V6OQIsMCufiUja+kGdB+mIhKM8V5rPlHt7cduaeG7kGJCpcuDj7+tPHhzFSyk4MA/Iunzh67uKg/b8ihmMstHGEh6azcL39iPtaXT3FzjK7RJYKgbIxxwDG1rbzbXP3HUfvMLxZrl3Ah3kp40P7YP2ysoaxZ65V2sW2At13JHzrVPz1zyahJFCVHAN9JEWDONhE3CUsUHF3fwwopBWDdBjO5awc9chNtEGzcYc7nZ7m1U2B3SxMJrVqK9PlXLR81i9Fl5C6sZUo03hucsW70Wyy4maZJb5dyzZVWbkx+PZi2IClV9AwYiuGxNrqG/U+UlYDlWYIzTcykY3JYY9KxTgU8z913bRn/ur/0ZITld5iCSRapL0xUpI13nfcIKkqC9BZqY6XuOLccPm0630SlwSt6NJG2+WKwSxPUQsnoLn8Fo9rdbOWos44a3qDrZ0o6G6+ryhVJZac9e0OoWEVfFuuNRlVmb+B6IyWbD+bOVYRhFqAYXwiCFhYlsIMk5VctZ/XCb1a/H3G+Rofwej6f2n8vsMD1zCSYcbQ6m7BsplAGdyo97yNp6K2R3IQdaKwiQWEqnWPpaymdCHEfc19tcnjPf+9fSoFVwzt0ud1SqyIuLHl5p5L4o73MVslIgOHmbCoSZhaj8umqKFHHi3KAPz8HVEGElUBCp6xT8gI AMEJXwSC auX8wwVrb9DzDRvYeRmxLVnYhrQ+DF0Anjxz/vYHoMQvuTNC7B4M9kSyB3HrMYM2cZKUyMYTjZf91mlm8U3pKd609g9NeyUwf20gPAxVyP/TAE8BaqgRzRMHA6M5MTj/zMKxJzl2/Zu5UcQBNcq8BOhvNJyhDOqHhVkFHB+RdDAHcCVQAEjAmDLBDZYp8Hl5XHhsRMdQtePJ1+cLM5QowWRwF3daUF0EmP7pbK3Oqp7aMFMeEJAnDTEFmx/VXG3WLOEDADvf+Lg4gNtcql/fmJisbyHXWX5e+RaGwubxk8DJiumvrGrUKHbt2Nx5e7ePnfGYIRZWonDxVnjR/SqNI39+RqUMOn0lC9nEcDzfoJR0P3k1N++CbnmwaoCejvjd8q051xnIMv5mKMDuxD43UUsQffyYi0buXBXh3I7ef3s/enh4= 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: > @@ -860,6 +892,50 @@ static int restore_sigframe(struct pt_regs *regs, > return err; > } > > +#ifdef CONFIG_ARM64_GCS > +static int gcs_restore_signal(void) > +{ > + u64 gcspr_el0, cap; Nitpick: use 'unsigned long __user *gcspr_el0' as in the gcs_signal_entry(). It's more consistent and probably less casting. > + int ret; > + > + if (!system_supports_gcs()) > + return 0; > + > + if (!(current->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE)) > + return 0; > + > + gcspr_el0 = read_sysreg_s(SYS_GCSPR_EL0); > + > + /* > + * GCSPR_EL0 should be pointing at a capped GCS, read the cap... > + */ > + gcsb_dsync(); > + ret = copy_from_user(&cap, (__user void*)gcspr_el0, sizeof(cap)); > + if (ret) > + return -EFAULT; Can the user change GCSPR_EL0 to a non-shadow-stack region, fake the cap before sigreturn? copy_from_user() cannot check it's a GCS page. Does it actually matter? > @@ -1130,7 +1209,50 @@ static int get_sigframe(struct rt_sigframe_user_layout *user, > return 0; > } > > -static void setup_return(struct pt_regs *regs, struct k_sigaction *ka, > +#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; Doesn't the second put_user_gcs() override the previous ret? > + > + gcsb_dsync(); Wondering if we need the barrier both for entry and restore. If the restore happens on another CPU, we have the barriers in the context switch code already. If it's only the kernel writing the caps with GCSSTTR on setting up the stack and checking it on return, a single barrier is sufficient (can be this one). If the user can write something on the stack or maybe doing a sigreturn without fully unwinding the stack, we may need both. Either way, it would help to add some comments on these barriers. -- Catalin