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 B0F14C3DA4A for ; Tue, 20 Aug 2024 15:28:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 293C76B008A; Tue, 20 Aug 2024 11:28:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21C4E6B008C; Tue, 20 Aug 2024 11:28:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 095606B0092; Tue, 20 Aug 2024 11:28:42 -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 DE9326B008A for ; Tue, 20 Aug 2024 11:28:41 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 260CEA02F9 for ; Tue, 20 Aug 2024 15:28:41 +0000 (UTC) X-FDA: 82473006042.02.41EF3CA Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf12.hostedemail.com (Postfix) with ESMTP id B858240013 for ; Tue, 20 Aug 2024 15:28:38 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eUHjXyZ2; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724167661; a=rsa-sha256; cv=none; b=2X35X+ALYcdonygv7D3sjGEX+SIhEKPh5+oWIpk/A+/F8+/fWwdOX0z208r4ZXMD8UDNKE /J8gsFfaXxz+DCp/ynMSPpGVpYhAFenp/Vp6YDHhegQ0Dnz7np98PyZoaYabVsaEBuoux+ MCkruJcOONA+5kbpcPEnx3rodZRwGsA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eUHjXyZ2; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 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=1724167661; 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=Agv/ctbgAxYXZXGbFSjcDqvnbZ8BWbv+Zz52+4/Bthk=; b=HsucCfs7/kRJ9tTwTpbIRNZq6oRghwan+aKbIl/NdA+D7sFSswhCwtkt06Zl9mi1nQVQHF vEm7P1hqA0yzI7CRysgnUV0wMgv4QAFDn+vD3JqtEeDse4zsGKzeQWj1q7GoPK4a+7jrdn VrArzUnEdbfdta2zJ9/MG3CDgS5/iX4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9A90BCE0B61; Tue, 20 Aug 2024 15:28:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04A68C4AF15; Tue, 20 Aug 2024 15:28:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724167711; bh=xOjQogCtboiaDEhhAKTxRH8bKSHT1uounx3l9TGETkQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eUHjXyZ2cuMRwBZU5drzIzAGHafYcOZVbd1dCQIvRqjL+mp8tIA7XyiFy2cCb1lAg shLO3+WN20Pzstfw7TIY2Fm2/7O7P4rPMgRslOFF8FRrg5Tw2W6K9hg6CDeDyr8s2Z dKLgO9QioVdce5HjIPnrHbA9CcZr9rhwfYiWAECOhm3Baxn+aET9P9N/7KW01x8G0S /YxbQ0SJf9JMPYzBsRG29MU+0Jcbf2gF1OwWZVEZ7C4nAiUP1XjAknZZ1nqJiNVWhj kyX3Qc98DJ/Vu/F5kkqrEn7yAsqfSZ1u+3FxpVBchfgoZTJgonBtBTHqFWeoKMXyEt 2C+GLM3zIUHtg== Date: Tue, 20 Aug 2024 16:28:21 +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 13/40] arm64/mm: Map pages for guarded control stack Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-13-699e2bd2190b@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RmO2vT/CXaa26vbH" Content-Disposition: inline In-Reply-To: X-Cookie: You are false data. X-Rspamd-Queue-Id: B858240013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: isobsftu5wi58kmddf8ccsqxn4rcxw57 X-HE-Tag: 1724167718-667924 X-HE-Meta: U2FsdGVkX19UKJqkjAOzoTeHMAHPiNA6TFiBX4580xTnPKQLl/6OoRRqTXfWgidvyeH8jTdsL8hlOfnMPojYhDpknOD+In5RAL0W4r/B8BaRMU5tgO2HdpGxoKM3wl8fnfFuadHcSfANOKAMff2IIUCf5Z1NShvAYcCaKxWuexa9aNc7E0m4yyHwhYq7q49rliB0qMzdW63fi8YV2gvJfs1OoMvwfcbjWLfVrjQwGacqspYccuOqxn9STRNeyvvI9YBgZtIlqnhFWXq0ZUo3JuokCAwGhVKpZA7XQ015tKfDbyABu3P+aPMenIt+bdtYK16sGJr2IF7SBarGpdtU2pef0j79fQjnUOmKQCOCahXTUGDar7HbvPE23CDkF6Ux9uCHRi6b6GsbCL36F1NbReGoKWaawgjAla4FJtn/zizHeJ/NK0H/v03GMOR8Ll4g7mcptRGsO9ojqZH2iuARaNXT53Q7ZlVYBdcPPJ2smzAh3YfbrrREuXN3mEMg95nhkCd0exUUcqRQGCtwH/p3cMU96cCum6KNjs320xokoss0m6E5luxUKRv7e4xnucSVF7MkOj5QBZt/j8tnCyCpzd4OBaNY2aaCn25GWUDpmbIYTPZWYfLbZtvVciKtaynZv6V1reXE07j6L2iIb6iFP7Kb7N/geFm2yyh53gb5w206OgX9FxnLZumv350UyMUjzptPrNap0TnWjenq0HQ+ayQQFmeUOnf4L1IZNilCyaAx+J+AY2dvJCcKP02cxEFfOHH/YUcwmpyG80A4ZCQzKdJvQqeJo0Jwh+MyYS+y7oNowi+vDzZ4y8QjAiBz/FLfPKo2nlUICI61sg2fmv7GpmYWiwrLHCswGL0hlN9GuN3EJL/QSMiE1irB3h9S9GZ+DrnC/vAwhh4hspGyMS7TAoiM6ExgcmXkxoie+SSVR7lJPxFErtlViMFtNdRIx6YMliZbozUB327t5LddNcy ZOPdH6aT hgBJPO0alNv1twZzcLQahh8mGIcqPY4BhfBMtU7/MEVf8Vtt71iZG6+LELR3QpNyC8wKZZDvMprqheK7lYn+coDmeboUtvgw0RNevnNQwC464c+lS/5n5cW+ZoIov336VbYKOytNGlyesUr0/+AK9k9h3Wt3IXzF0qgMHu4gbCuPtnbBHkZciEy5lhNQDXs1dlpLKMrwTp0i2RQIQucnMtNH+gycv6xx484tDhFRz5enp6MrTkisfep9fAYL9k+iZcdP/y93qf8Q+osPmxL1Qk27uAj1huduhhKNJpI4uJ9MEYy/ULJhTSelY+V+zZb0+TnOP1wsf8/nEm5FQ1ZG0dNTTwg4hmfWJh52q 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: --RmO2vT/CXaa26vbH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 20, 2024 at 03:59:21PM +0100, Catalin Marinas wrote: > On Mon, Aug 19, 2024 at 05:33:24PM +0100, Mark Brown wrote: > > On Mon, Aug 19, 2024 at 10:10:36AM +0100, Catalin Marinas wrote: > > > At a quick look, do_mmap() seems to always set VM_MAYEXEC but discard it > > > for non-executable file mmap. Last time I looked (when doing MTE) there > > > wasn't a way for the arch code to clear specific VM_* flags, only to > > > validate them. But I think we should just clear VM_MAYEXEC and also > > > return an error for VM_EXEC in the core do_mmap() if VM_SHADOW_STACK. It > > > would cover the other architectures doing shadow stacks. > > Yes, I think adding something generic would make sense here. That feels > > like a cleanup which could be split out? > It can be done separately. It doesn't look like x86 has such checks. > Adding it generically would be a slight ABI tightening but I doubt it > matters, no sane software would use an executable shadow stack. OK. > > > Is there any arch restriction with setting BTI and GCS? It doesn't make > > > sense but curious if it matters. We block the exec permission anyway > > > (unless the BTI pages moved to PIE as well, I don't remember). > > As you say BTI should be meaningless for a non-executable page like GCS, > > I'm not aware of any way in which it matters. BTI is separate to PIE. > My thoughts were whether we can get rid of this hunk entirely by > handling it in the core code. We'd allow BTI if one wants such useless > combination but clear VM_MAYEXEC in the core code (and ignore VM_SHARED > since you can't set it anyway). I have to admit that the BTI because I was shoving _EXEC in there rather than because it specifically needed to be blocked. So change the check for VM_SHARED to a VM_WARN_ON(), and leave the _EXEC check for now pending the above core change? --RmO2vT/CXaa26vbH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbEthQACgkQJNaLcl1U h9C1gwf+L79Si923x11LZKfwuy0dQkE7LpTPSafOEhNGVDQZTOrYQW9x1homrSt5 28vBitZZV/TtBmLO+HSzt1fq5JM76Q0BaPH3ngunEJ0umUMkZwC3r59YzFHNXhQL THzCh+B05luDGr58Ay6K29M/I8JVGiXNBd+Ag+/LYQTq2HXOPC7lJimbZAU0aS+Q mV43kq/p+Ipazr6Bymd4tGQI5HjdMgMp2dhKT0bLH06aGJhif8691f8t9ZTp4lGX 1PqWpOuyg0qYDA8JAraUHsc+4FaMyygUqV1ZRC+aTjL/EVsIFwhvqeZzESS+C+/p C9zocGnFLEdepXWg3jQHODDOF+LxiQ== =8nDO -----END PGP SIGNATURE----- --RmO2vT/CXaa26vbH--