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 5877FC52D6F for ; Mon, 19 Aug 2024 15:57:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE9CD6B0082; Mon, 19 Aug 2024 11:57:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC1B86B0083; Mon, 19 Aug 2024 11:57:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B88606B0085; Mon, 19 Aug 2024 11:57:22 -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 9AFD36B0082 for ; Mon, 19 Aug 2024 11:57:22 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4E88C81357 for ; Mon, 19 Aug 2024 15:57:22 +0000 (UTC) X-FDA: 82469449524.09.EE727BE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id 9196C180026 for ; Mon, 19 Aug 2024 15:57:20 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZshOpuuO; spf=pass (imf16.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724082937; 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:dkim-signature; bh=PYLmV16KsG+zDzOmzTbBF+0R9xF2FDWRZkHT6Pize0U=; b=yCx3lC7TBJoUUbr68X1dTjrNi4yeRLDEl0Esg6OrWTcyMrfl68QTT8f4rDdW3B0QoEG6qE SafDDfTH4mXh+1chBvUBoIkkZR6WST26jQaFm9QHjJ/fqhqNWsS0Z+Dmev4DQGrpBhxIRG IxBOdZYaaXXF+9k2SdK0GOqor1zMhSo= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZshOpuuO; spf=pass (imf16.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724082937; a=rsa-sha256; cv=none; b=0NEtdhbqv/moouUqO45aLGRgpYZYakZLvm8QjXE+7uUv9EEi2YHS6bJ0VQ9g3WFHv4FKRd /Io9diMOSfvD1lJp8fY+Raf2akPDA0+dHL83Sslw0TJIb/MzMsvwH2TNfOZz7DuyBI6RA5 IvCj1460aeaz8kPDaJd0aWpvkRP1Zjc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 96EF360C5E; Mon, 19 Aug 2024 15:57:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4129C4AF0E; Mon, 19 Aug 2024 15:57:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724083039; bh=v3qZPwIeSRlS1QcsBxR5WSu2pfKLNLQcLI/q+clxwYM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZshOpuuOha2m4jngC5/MOOet1h6SG+jGlUt+nz0zAcvFxaYVevSimDv5TPH5RhGBk n9vXYpX2cb21q0uvpWQv1L6nybcMoVEMup5m4axyZt05/rSJoSBjekbnGpY8sr0ywF Gnp2cqrKP/n0xk9tO5th3hGes39+M3iEGePBCZbWExauae/tlRw3tpDARhLj6Oorsg rIN5jPdnyNDiNGWeAYS7CxM75DLtEWLAVknNiDb3ExafscAPpWC0uwHsY0zKDE31ie 0Qn9rSwvoAU5BKY8j1qsz3b8iuKoZrmb6ZqECQIQZAr7Ul403nM7FWVzz2x+/GzUCl B0n1sNxvYU1SQ== Date: Mon, 19 Aug 2024 16:57:08 +0100 From: Mark Brown To: Catalin Marinas 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 20/40] arm64/gcs: Ensure that new threads have a GCS Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-20-699e2bd2190b@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RbrhEhE3nEZQH9R3" Content-Disposition: inline In-Reply-To: X-Cookie: Interchangeable parts won't. X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9196C180026 X-Stat-Signature: pyu8mgejui1c5bxgzmtmxou7haxnh6gx X-Rspam-User: X-HE-Tag: 1724083040-189981 X-HE-Meta: U2FsdGVkX1+WXaPKYtUFR6S2ZxStXteP2nS2ybCBICQMkRcqw8ybuBLeOJiCWuid8KzBJlSopDC6iiL5jhp/ph9h9EAco265Eu2ja0SKOUEbTgpTLHOZIlCz7e4qRl1hCHwUXSW/0wi0TrdrtCFS/4G1+6KDMdEe0MVRo2f252k32F1avxOr2zwYSyTCK9/HcQ7ZbkpmxmlpBM8Cg5S29LVkCNR36SxCev/CDkkPVbPmLLQE9vi03LU4z7r+99EV/o+UkiV4ql0bHqa+ACjJthkHWQ0ATEvlqMLTdf44oIp4vtLnvw1jLeQwT1tUzwUEY6b0H0HaG/fA9YENfTkCWouXk3tNolJb5Qnd2n/a4/ufd947fq6s+KxClFUI6P8u6sq544RMrYS6clvp37CIpOOFqoIaW4n/yLfMBp4vOvGN0tiK4NR595zFWVI8wxOQ3UmkPoLSGSO+qIh5P6KQs/I4OeTDpLDhMEOTrmwFTYP5gSz0aHbqOHB48irhPa10ygwPpM7oiQ6I6Cq+n9lSXXTkiz82JH3Y/D7pWYDY59n/ftN/iqUsqrx2gMSTU7uSKML7Vtt9TNjQlZgFkVVcbzlQCzu89545Y/3GPxWvhsnb5ujOOYESkOi5dzPgdNXoP9GvpIFniAfscJor4l7WycAOzGhYdLtdnlhlVP74aX2tjI9NzS7yBcT9w7A2h60JXOS9QZe5X+pWSDz+ZN7K5wkat7rAe4hTfEfID34cfJusbvwqGrBDiP57QQb08BqyaqdC3gRByZuuQ5CpCOBumYA1RC9qkGvDk3lZCc1So0lYmixNHOVc8q2iomUWz3/6ibh6DlwKM2zJZdp6q6J8YucCfl5ToLd0sQ10QQ3W8imPQJro9k5iwjEyTdFx5bACpt/GUj6lecnKVK9ZUEne0XdyBWyQdlMvAptoDFZwRfhimigfCKGgBW/IC43Po4adlCncjr49E1R0+NldjFJ q0tMXMBB nnoVajfsNlnZ/6T8Eq8E+oWFqutGm1dxasngnADbPIM3rGDQs6UOZUKDbUrAX61/P44J4gfazNRFKyF7dkZE5aEivXuCjJr0jcqXLhh7p+mVcuVM4UxYj0AhSwjJrqyDNyWYBNMlCrYnNy/vpEhOQReDyf9KMM/7K7u1Y47NKTbBKhF0tMiH4FvhHaknE+CJfyS5iR7QPL/NsK3kZLUg6J/tW/2BTYVHJsTwKE5sFyASlxytuedZ0W3cxZGErwZzlyfjKYpC0OwSD+BxasFQM2jlfLVH+V7lIRQzRcnDc+PYfo+Qo8JSpyVJZVpEAEVCOhuneOH+Zovvch1NPiw14eM4t/VFVAPgmItru 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: --RbrhEhE3nEZQH9R3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 19, 2024 at 01:04:18PM +0100, Catalin Marinas wrote: > On Thu, Aug 01, 2024 at 01:06:47PM +0100, Mark Brown wrote: > > +static int copy_thread_gcs(struct task_struct *p, > > + const struct kernel_clone_args *args) > > +{ > > + unsigned long gcs; > > + > > + gcs = gcs_alloc_thread_stack(p, args); > > + if (IS_ERR_VALUE(gcs)) > > + return PTR_ERR((void *)gcs); > Is 0 an ok value here? I can see further down that > gcs_alloc_thread_stack() may return 0. Yes, it's fine for a thread not to have a GCS. > > + p->thread.gcs_el0_mode = current->thread.gcs_el0_mode; > > + p->thread.gcs_el0_locked = current->thread.gcs_el0_locked; > > + /* Ensure the current state of the GCS is seen by CoW */ > > + gcsb_dsync(); > I don't get this barrier. What does it have to do with CoW, which memory > effects is it trying to order? Yeah, I can't remember what that's supposed to be protecting. > > + /* Allocate RLIMIT_STACK/2 with limits of PAGE_SIZE..2G */ > > + size = PAGE_ALIGN(min_t(unsigned long long, > > + rlimit(RLIMIT_STACK) / 2, SZ_2G)); > > + return max(PAGE_SIZE, size); > > +} > So we still have RLIMIT_STACK/2. I thought we got rid of that and just > went with RLIMIT_STACK (or I misremember). I honestly can't remember either way, it's quite possible it's changed multiple times. I don't have super strong feelings on the particular value here. > > +static bool gcs_consume_token(struct mm_struct *mm, unsigned long user_addr) > > +{ > As per the clone3() thread, I think we should try to use > get_user_page_vma_remote() and do a cmpxchg() directly. I've left this as is for now, mainly because it keeps the code in line with x86 and I can't directly test the x86 code. IIRC we can't just do a standard userspace cmpxchg since that will access as though we were at EL0 but EL0 doesn't have standard write permission for the page. > How does the user write the initial token? Do we need any barriers > before/after consuming the token? The token is created by map_shadow_stack() or as part of a GCS pivot. A sync beforehand is probably safer, with the current code we'll have one when we switch to the task. --RbrhEhE3nEZQH9R3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbDa1MACgkQJNaLcl1U h9DbuQf/SjnwfLskheecxP/Aw1iuvcdM5Lad9HYiZl1LzHJXMVCIt1kMcKPJ3MS6 O9iMeWyDk7d7EKrWneyrvSODTNZAFjUnExoo/+WNpnaumrwTH4vS12ZNpq7/1a8W AsxmGCrQ8IsHpSkEuJyMKshASponZtgCQwUqQX24QyTqP527qXCrX2VmwKppiR0K 4Ve0jwxpZxGhlRUdEWD2k1yIsfxh8qa336gUFDOLxmwW1SRYdQnUpfDzrBg1Kj7m svrFPBMCQySshntbpRCF0xNG2bxseTrXAKwuqFM1Om5CwvV5DVSRD1n7AaaJmOm0 Gki/1SM6NelVLm9JiPdHIZCf3bkbZg== =dVcd -----END PGP SIGNATURE----- --RbrhEhE3nEZQH9R3--