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 367CFC3DA4A for ; Mon, 19 Aug 2024 15:14:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87E3F6B007B; Mon, 19 Aug 2024 11:14:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82ED66B0082; Mon, 19 Aug 2024 11:14:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F6386B0085; Mon, 19 Aug 2024 11:14:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 507E96B007B for ; Mon, 19 Aug 2024 11:14:54 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E4EB7A13C3 for ; Mon, 19 Aug 2024 15:14:53 +0000 (UTC) X-FDA: 82469342466.12.B323E71 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 267374000E for ; Mon, 19 Aug 2024 15:14:52 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lCYk6sau; spf=pass (imf01.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=1724080415; 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=ZXTKf5HWGvF0CdC42s9ElppufZGNZZduVWJpglpMs6I=; b=BtNluZc1ZD11PR6O/6Sh0hROCgH17R8ywHDkgfEMizZ6dfez41Jg5Kf0mzqfRNV3tneRc1 1ZU9BxL8ox4pQ5745DM7H913SwLjoErNNxPsNMKaH/Kde1eiHOIf17930femqCu8qxDxn3 /JD89Y4GmpY6QI5nkxzRASVz3WDzOVY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724080415; a=rsa-sha256; cv=none; b=FfQ2oJtGhbEC6lIucNDHvHUCxqVKulfkcc+8dryr26eAgq/Ssc0dU51wgCzytYmAHdhEbN V3DdOLQfcVWGYGpvTOg7HfkMdwh0uImtQ9zTUC5eH6uiEqw83CZ9VTBjr2fC10csHgwRs5 IP41NuzarntLJ8UH/EyDeVHUE2U3qCA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lCYk6sau; spf=pass (imf01.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 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EC3AE60C4B; Mon, 19 Aug 2024 15:14:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33AF7C32782; Mon, 19 Aug 2024 15:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724080490; bh=S8xLhlX6RpZyNHWb7anPniOddgqkLHLd/F+Q/aXteFs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lCYk6sauuzGZXdmOUXd2qTfJWvnED9bat34saswazgl+M63wcMrmkDGih3C8kQurA Y2P6GJV0apLQodqEjQKA4tdHpmZayAUehizPYmJryKzc9k2pe7FjLLsB+nMt+yQu9h 6haqcAo1ROW4FSaTAo1ixtaogoPe/ZoVBT9tJrC3lFtzrBO+EUNak/Eatw3H2Lcpe/ c/nYpouIZebXmyZmxMOP8ewWLGfSRVwk2VIvLTWpC+zyPpx85rnhXiCbZ9E8XxLZ9C WuivjB335AbSXgBL+2B1hZIrxM8FYBoq6IoTjhDAc4WPE3BbvP3auleWIgXw19OJYa wCRcfVWJ45ZMA== Date: Mon, 19 Aug 2024 16:14:41 +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 18/40] arm64/mm: Handle GCS data aborts Message-ID: <24d33455-d958-4f27-8a2c-4f237fc2bd29@sirena.org.uk> References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-18-699e2bd2190b@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4ClE/UJ5laHl8PFo" Content-Disposition: inline In-Reply-To: X-Cookie: Interchangeable parts won't. X-Rspamd-Queue-Id: 267374000E X-Stat-Signature: qqsri44ug4pwxdhxa3wuwrmisksomstr X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724080491-298225 X-HE-Meta: U2FsdGVkX19q+sW4Em17mV4OVasVy1HHS3NYDVXJ8r3UDbaVYDnX0ex34MF/f5en4LFFLiAAg5gIhyzpC+qMfcxfynf4t7xbtYdfyYoVefQUG4luy6I4u/VtUiaE9l59RHq6Zwydek8oEaSFHIwxB+RJIGPA8WgZoQwcxW4ATbQlAhLnBGcwiZKlP4vzmtTkdq/s+jp3eAJD/6hCAELgJnZXopJkZf+DU2Wd+glMqQcttxKKWQW/yqFVjD54EjDSp3RTGfdmwgLUD/b4ZbCyjSQ2u6pgakcqF03SrxcroUiHpoudyM502hU7ewZDM5b5T68r4pqdTAoV8AulLFT/UlxYRdgADMbpGBrfRbObdSUhq2yocM7lIh9NUb0dmZ3qjQcyTwpA2ExJEMGvScVU/bG1NwivKlPU1ONh1hdz/s4Vo6ugcIm3Pf9tcxv4h2gZMzD12HFpHXqEku9UmzumgxRrERc+Y+lJIzGil+SrxtHqzgfo/FTlhbcUE9mYXTMn10HnXMBsTXlns929LhdLotBJXobkOqto9Ye652WvTIx5OIVy3Pdx5iXaLZbP1dPn5MnFXYQx96cH+54Wuo2ZzXJf1yUTqeJeUMkQWs+nT+b/T0oilhto6uW9ZAXCNTLYReeAC8i/J98xo7SYFUzkN+MPyUy4Szra6PSik4b9chmmVJnPPXnJIqj26FoqjOyD10Qp0s76RZTxBxY4rj/HqXdbtg/OP0kS+TXC44XlFkHpDIY5bctguX8Pe00nEiTDZna7aili1bJMsdOu8w9tqPZ9YBdW6EhuKdWnV3/CfSit6VdbkApZfGnKGEeygxLBx6oMZx4qWSkbdQnkvFSX64MRiHu5uQzxyMwqXqdXgk4kxOargE+YAMenwz9ECcfz+mavwEzhwFp9pi/t2EGN36i7nI5bGxBkoXSYL2wB5N09o/CMJNt+rz7jKSz+tA7hFyjzIOeeg+r+mk0v54C q92QZ/Hh e7UP+bQ6i4VDgAsYWK3NMiMZ1fLCibTq61PcWp0jCrutQszKm+lWySk5H/gnFLqsjKx2ZEOiI5mmNvsMBDVH53WpwugID+3d7p0+GOGqK03mFuL6cxMjM1NMD6L5rNYpLZ8+/OQ3UCRlQNTvi41KM3wk9uufOSAJu5mlH1h+BnwIUCmYUv3O1PFzqZqwCVzJ9V4Kl8I6O3DqtRI9E8iVBDfyp+cfnb30AHMR4W0hmHnbCfaHasihM+KyEYlwHVrqPSMNI739FzJo4dVAnu64NrFuZz8pkDtTaTrCM23XewPmn4/TP3IUian4FtI+i9D0sAnks3hmSPYGpGhkvE4KzUNQxvb7JeOu1pdmAW7qZM1AOnKT8DaTYbjZ2Wg== 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: --4ClE/UJ5laHl8PFo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 19, 2024 at 10:17:52AM +0100, Catalin Marinas wrote: > On Thu, Aug 01, 2024 at 01:06:45PM +0100, Mark Brown wrote: > > +static bool is_invalid_gcs_access(struct vm_area_struct *vma, u64 esr) > > +{ > > + if (unlikely(is_gcs_fault(esr))) { > > + /* GCS accesses must be performed on a GCS page */ > > + if (!(vma->vm_flags & VM_SHADOW_STACK)) > > + return true; > > + if (!(vma->vm_flags & VM_WRITE)) > > + return true; > Do we need the VM_WRITE check here? Further down in do_page_fault(), we > already do the check as we set vm_flags = VM_WRITE. > > if (!(vma->vm_flags & vm_flags)) { > > vma_end_read(vma); > > fault = 0; It looks bitrotted, yes. > I was wondering whether we should prevent mprotect(PROT_READ) on the GCS > page. But I guess that's fine, we'll SIGSEGV later if we get an invalid > GCS access. Yeah, that doesn't seem like a particular problem - the concern is adding rather than removing GCS. --4ClE/UJ5laHl8PFo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbDYWAACgkQJNaLcl1U h9CIagf8CVGRJRPIYEL8OXtLlRDHe/BAx31NyJ8PnnV2H/LyZ/HkpxFqkEdopZ2W SnomGLDZ/Sbry7VZUUVbO9QNmD/7UinwFR26WOigUY8aHtv/SDsMpx68OMvMPGtp aOgTkLDZdZiL3OZbxsdYj24aQ2gywicEb/JxgcqYwclQvQn3geXt9wvBJIZvUqOI f9ioaV7/pP5zWb35Kra+jjC2CUxouQ1ozkrxlJhyTT9VM3I4iefpf6eaGmgah7G9 n5vrIJWkdxaC4B8K/p+Uk/2LJYWdvOho+S1PnJPJloXX/3+dCvveT+3yVcEzT1z0 73smiFLb21oBkc5wjzRqiGDdQA7z3Q== =d5gu -----END PGP SIGNATURE----- --4ClE/UJ5laHl8PFo--