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 8848BC04A6A for ; Tue, 15 Aug 2023 23:54:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 200F8940039; Tue, 15 Aug 2023 19:54:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AF4A8D0001; Tue, 15 Aug 2023 19:54:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0785A940039; Tue, 15 Aug 2023 19:54:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EB5C38D0001 for ; Tue, 15 Aug 2023 19:54:43 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BBDCB1C992F for ; Tue, 15 Aug 2023 23:54:43 +0000 (UTC) X-FDA: 81127996446.16.46ED062 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 0ADDF40014 for ; Tue, 15 Aug 2023 23:54:41 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DxIy5vbU; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692143682; 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=cRtU1iHpZakw568z98K1SEy1uFX2nGssPNiWocKuuo8=; b=jdLgOTWJOlG4N6aFuNEfOkZHep980Ie4vrJQGFXOHbo/LM4eghXNjSG/OOxRUEd/qZo/dZ vbgP8LAVam5nYkqcsZlvfMZI/2/RwTZrLWw/l8sBp9nC6JkhloFYOUj+XyphcbTmm2+UvH ghPjRfcQ3iMAA208uUYoiEPURG4Cxfg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DxIy5vbU; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692143682; a=rsa-sha256; cv=none; b=8oslLcPDg/8wuz6kF0AhDL3PYHbSl/x4VbycvzgGZyXqdWWglxIQvXTwo9hbqPk8UOlt1n ffOhy4X3HXVgOFZ76RNX+pP71QyOuZOUzC7oJloIpwJtiO5o2q0q60T2ZVJr+9LeThbdQs zlzBx7Zb7ilOoc7mrg51BVNVJsqLd2Q= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F033860EDF; Tue, 15 Aug 2023 23:54:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47CCBC433C8; Tue, 15 Aug 2023 23:54:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692143680; bh=n6eEACiqimpPB7PLvfd+oUPFPVhzIcPuBLC1dr7dvkk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DxIy5vbUapbtWP3sld3mWYjZBRmjMrNODKGFDnO97nPi0kw+utGl7YhSUxRcSA55j bgF8O8udbd4TU+m5lMdm4Tq8mz2Iji+2duH30c7Uih+GPjDtxMtERbEdC1HkZkRbV1 vhFKi5KpL9sjgdjBtwcn8MOqnv66AJbhzBkjh1oYLzW8TtTXJwoSBhyLhul3VdRwcO 1WhbPKDlq0Tm06lqfY+xHm0muT2Lor4Y/lV59laZCZRREuOI6SYgQstfXcPOumpgOw HGCLOk+Rs8gWd4G0xWygKex2ny89KElnHHwFax3NDVcmPkRCbi5eOwwkFR7OjQVK7e 9jsYzSH7oiqSw== Date: Wed, 16 Aug 2023 00:54:30 +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 , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , 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 v4 17/36] arm64/mm: Handle GCS data aborts Message-ID: <752f9f06-69e3-4e60-94ca-49cacb1122ff@sirena.org.uk> References: <20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org> <20230807-arm64-gcs-v4-17-68cfa37f9069@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bU0eg43A83FLgDHm" Content-Disposition: inline In-Reply-To: X-Cookie: Darth Vader sleeps with a Teddywookie. X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0ADDF40014 X-Stat-Signature: sdrx9kb6joys43diytrifexwncranukj X-HE-Tag: 1692143681-329160 X-HE-Meta: U2FsdGVkX195yT/1Lw78+P37mMk0pklmMPcS1aL99UTV4p5fSNsmIzrpFKf9ZYK8kFj1zN8OXZApTkwOUDtf8ulz5ozdyWpqaqozJF7caOKHqa4mQliuSdi/zgBtaGplyjoC780Yv0vzerfSY/lBXkCgZzrsLV6txugvTOAMeyS7NcNxG+a64tfxtNuxbA1GYLZ/fgrd/sIA/x6JlcsumTF5FE7pHUdNtcH9NEjZ+BjNea6IgbJeCSUlrw8Tg3sGGn4X+WDmktlEAmtdHKxS5NfCOsoUgwFTFMZbhSUdmJdewJZzhi0kOVfOK2z0vw/baP2+ZFzsaB11VniF5FcXuca1AVScec0X49R1u2y8Euk+f99zqgt3REe92oKwqq2Mi3ytJgJUCF02q9bpKWxODEdzK1IGG2CF3OPUrqEUdYegJtQo6ke/vk7mJSKVlhZ4l9tAI+qqA7DKnIlYVChfWEJYpo2F4pERAtEr2eqJeY29pRtaysH27XkEChhhs63oBnQ8HMkV1f3Vxe+JSPOCSfQEhpWdUOTbzxJInNGuhiSwGZaFzRc9dbBmqfCXlaZ2Bdccw6F7YzrRD3CyKVHBGYcqw1Wo3UQy4yHDdLGKoqxoMXR1bexJYEeCVaWIGOAWQqdoFonzC/B6EByneGBR5fhGVvlRkUADpbkVUDS60JKMGMzvnFYCD34SFwVIayV+7EO07oe7v7i87kGm3CWQS7g79HzEhjLzqnlQTleWsELwqbTyQrN644xYlvsDt2cXg0cUSROMn0IRFq4Jo5FWw5nsvAzmEctvlHAtXupoVV2tMotE/veQqicIYzh2iYW5XtaVEwVVn4uGAjRvHpwXr6OY2YbBQ7g7l/vWJb0ckEHDGdeGBVFIRkHxsxh7oGt0pH9ScN0GdrztX4LLlOK2qsfB+YYMReHkfzsaxx5Tz30bQOjSOnxaL8grG0wSteR5MhsiBT+r10sZa9UuBpt hil7+Zw5 XuZMRi4yUxcVJNbRxdCebs1L8+nfZlqn60ZQSVkhDwq6JrEpIv1ob/PNOFE26qq/jIXodWL4AJcAuFoaexzlnLx6zTiZmt4Bo390Zr++36ALIZtWwA3U6kMfX0YilT/+2nTgyg9gv9aJ30rXudPQP+k6qbrSssF3AqHAp61d2LP6B6aDIQGOY55M25iyemkhN4pkFg6ppYUstr7u/gHOWWGhe10a2BWIfMFkbYvqPZGfuDlAalDB7Vz2ZPHv3Jax+oQNvAXv3lz4G2Y8eYuuuYlhcnFlpLR/4XK6wvPH/tGJE9dSUOYWFx8h1A/+UbFFMuNC5o5BeqecTCDZq+w6CmLu/PR5gzsU1zoZXcK0MeGfs/NsT/QaPl3TXLwGaW38+axaC0yHbBaBRwZ6k56JG53G4Z49RfZc92ODA3UTyS20+i4s= 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: --bU0eg43A83FLgDHm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2023 at 04:09:33PM +0100, Catalin Marinas wrote: > On Mon, Aug 07, 2023 at 11:00:22PM +0100, Mark Brown wrote: > > + if (is_write_abort(esr) && > > + !(is_gcs_fault(esr) || is_el1_data_abort(esr))) > > + return VM_FAULT_BADACCESS; > Related to my PIE permissions comment: when do we have a valid EL1 data > write abort that's not a GCS fault? Does a faulting GCSSTTR set the > ESR_ELx_GCS bit? Yes, it should do. The GCS instructions have access descriptors created with CreateAccDescGCS() which results in the access being flagged as a GCS access. > > + } else { > > + /* > > + * GCS faults should never happen for pages that are > > + * not part of a GCS and the operation being attempted > > + * can never succeed. > > + */ > > + if (is_gcs_fault(esr)) > > + return VM_FAULT_BADACCESS; > If one does a GCS push/store to a non-GCS page, do we get a GCS fault or > something else? I couldn't figure out from the engineering spec. If the > hardware doesn't generate such exceptions, we might as well remove this > 'else' branch. But maybe it does generate a GCS-specific fault as you > added a similar check in is_invalid_el0_gcs_access(). Yes, see AddGCSRecord() and LoadCheckGCSRecord() - all GCS initiated accesses need to be AccDescGCS so appropriate permissions enforcement can happen and that's what causes the fault to be flagged as GCS. > > @@ -595,6 +644,19 @@ static int __kprobes do_page_fault(unsigned long f= ar, unsigned long esr, > > if (!vma) > > goto lock_mmap; > > =20 > > + /* > > + * We get legitimate write faults for GCS pages from GCS > > + * operations and from EL1 writes to EL0 pages but just plain > What are the EL1 writes to the shadow stack? Would it not use > copy_to_user_gcs()? They should, yes - I'll reword the comment. --bU0eg43A83FLgDHm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmTcEDYACgkQJNaLcl1U h9A2rAgAhd1tNqwsfCv0ZnuQlRFZyTwPwFCn76BeqIuV3TYu4Nymed/YLhOECsZ9 H6Fni+Igkf4ckDfRhk742+N6QqLOBZz4ddBTJDV74NJk7EgWWv9srbi10k/thyIT O/Wz8nVnuUHHXN3dkJIZJQ/l6GjLrzoiskqkrh9ft7HskvTTe1DOL8gFS8Qa5DjS ut+XhC5VI7HX7iBwhhqw1tEjsQM3ldnl0r/rSd37tFbJbDX6ujuMlgpBKReSH8qV kfrNbgpcBoxaKvE/rytuAXTIS2oqh/1yHuWi8ujBlZgGf8Vo7OK0alzL8T+oIEaQ 92UJwq3fW51GVCMDxbeaCh1vD7hrKg== =cuH7 -----END PGP SIGNATURE----- --bU0eg43A83FLgDHm--