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 22242C3DA4A for ; Mon, 19 Aug 2024 16:33:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 653956B0083; Mon, 19 Aug 2024 12:33:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6036C6B0085; Mon, 19 Aug 2024 12:33:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A48A6B0088; Mon, 19 Aug 2024 12:33:41 -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 2C63B6B0083 for ; Mon, 19 Aug 2024 12:33:41 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BD0BA4122B for ; Mon, 19 Aug 2024 16:33:40 +0000 (UTC) X-FDA: 82469541000.17.0D5076E Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf09.hostedemail.com (Postfix) with ESMTP id 692C3140029 for ; Mon, 19 Aug 2024 16:33:38 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="p/Xaqf57"; spf=pass (imf09.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 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=1724085180; a=rsa-sha256; cv=none; b=Gmatk4VHnY+EYAi5P3e8qKm09P8que4ZfcslDSuRObHsjkblopgZg7QtqXG8LRazLZLriy QHWnbBIHYSp3gdjsr+N5Ozv9bbeQ4dDCiau176Th3Dec+8LdwtUjf8z7tu3fVWPvWKoMTw x4SKHu7cbWTTPi6vjJN4LRGUKMp2Qp8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="p/Xaqf57"; spf=pass (imf09.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 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=1724085180; 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=bRUuz19yjhAdzobHGVnzPMunMclqlbkKzGp00xZirnQ=; b=PcE39AkeMD+GmGsG/aZaXoqlufctnPnGpOMO+YXbfk/YsIJizDQDQhl5Bds+xgEoHYnKv5 cgTGp8KtPvMxnQ4575RbMSoZzQvOrTEALU17efc55ooDVkJA+F+zQIyjCMfgGDbFOxXTDH x2tfM3pBdjOBZ9eKElPQiuUya7RKA2I= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id EB5AACE09EC; Mon, 19 Aug 2024 16:33:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B21E0C32782; Mon, 19 Aug 2024 16:33:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724085214; bh=evii6L2sZLuBZsDeVmQaiukOZYaMAFg0RqLOntPinT8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p/Xaqf57XaWAVesDIXzLwFNmcsGpxCWxCiEl8e7wqsfX6gbZTVZaibIjtofHP+HQy mNkfUOElC8Ed0VjXXvNq9aoGwmAtJUoqRfPxjW6pG4WzPvDPwk2E/ohMtDCdY0XuRP 7k9QW/RaYwIiYXeuG0zIRmMObdLvwZzA0wsODoXlGTOLMwINsKdtHKc+TgwAqr4ZO9 DbshXmifSQvXAnQSw7yxsDdm+PnnWXUw62cMAbR8DWLupzNOAJI8jMLgI1UYKzU84R zNfPjPPoV8e0rLVIwnBnTaZ7upD0UC+dpiqjmwOqR5FFGfmA4YvEC6JEHoxtzdMqKk RiCeykpYkKbQA== Date: Mon, 19 Aug 2024 17:33:24 +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="eyTciqf51C2CbNXu" Content-Disposition: inline In-Reply-To: X-Cookie: Interchangeable parts won't. X-Stat-Signature: q69zcygw31cqup9hjg6i6om55gqjhsf5 X-Rspamd-Queue-Id: 692C3140029 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724085218-392838 X-HE-Meta: U2FsdGVkX18DI7HU1y+wGF8ZSKzlL/cer0iRfWZpkzoBwbAPA4A1K+KbNYKtK3LwDAt8EHjukyeMLQC8gSJHrc1gxnL52lImWAXSAjVfcd4ujqUP/fcRrwcnFMNCpLy3bJ4hCsZQc/z9v3PJP0rDvRc6R0R+aopyiArK84c0wTqFMhz4b51eCNIPdgT5s5jtbAd64o5qodUJdKS1un8XLeePTlQA/l1vFCfCCGbBbNCPV7K9Cmrf1ReC5HIWfhkRzmpg23c8w4+PWWQ2v9JPfPlEF8gPdoMeGdc89IdKMnxUReKYlfMRLnGKF1y0ckvBGk7Qq7lcLOrR46oDKicWwVMJMBP0+dH13RRXSbxs6a4bW3J+qggYSTkNkGOmfcZNlwzMQ8eMYG5jPC7q85n5ol9JokD1B6DoMwo2L9ZO400xseaYrR8ak0RugHVmf0h1N/ojAreeVei0A0nTta7OV/yob16M0tLqFY2y9MV8YB74w5r10JpyFW3mt3smOsmQqq98C/GUioHLe3tFwG6IiNp7OTCRUlqQ4vdJbBkbeqpjTu1ZW2KIIfQBxuatVKFOwZTfF1OuZc7OxA0VXlNlHlx3SeWBJT2vu7y8b+sC0bMkadNaW8EANj18DTgY85mvu7lb0s+Hy1bybffH7opYU0r1jUWuU7sese6XfNHFpphlIyhK49mKuLdQW7RJ6/C+4sJScUG1PSg4tZF4hM3sCSrfjxTasTY3T29wV7C5FCYYbROVaIMbqfrMIbr45LH/cMAcPdCJUhgCj86taeIl1ClZZU20F7jU9TKENkDwxuh58ZYMDL0r4ol0HguCqRBGbn3+cnW5UR5jjjfLPuX/aZJISZzm2pE0X6kYd6u8Rc0XEjOmSLag4zxkdYFOZbpIEaqHhH4R6G+nj8e8tXOilgRQCa0wKNtsV6tOKK12aw7CR1BQ0Uf37f3hYoAcgYRlJ0pmvj1OcSZgrZL8wUa cBXc2G9J 4NHzRLw76FYVK4FUIrOG5jbprVgkGggl67JgRW5lkw26ALTLezylbpRV7z0JeSptPMztWQHWY+K1bfcloAFDNBEmg/VS26MfbCQ0jkViNQGTQgjETtZeTy5LfZhFFtm7ogElyxvjLBOiq9cdFN8VnRoNJt2E8Cado7AVm0VF4OimMH1kUqjID644mExkwLY9gxb3aIvIioV9KHgSPXcpQwVHbgddJoN4JWxgJouJQ3SqEEDy86hoR9Vc7l4vX21tyXKwhRhP4E7gh5ASq9HpGBzupygWN4kFb7ZAXHKH6H0ogSkp5DDT7H0ezcHRBul/vKON4aQ8W17JIJbkH36xKTVRUpu/WG+hU3kgA 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: --eyTciqf51C2CbNXu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 19, 2024 at 10:10:36AM +0100, Catalin Marinas wrote: > On Thu, Aug 01, 2024 at 01:06:40PM +0100, Mark Brown wrote: > > + if (system_supports_gcs() && (vm_flags & VM_SHADOW_STACK)) { > > + /* > > + * An executable GCS isn't a good idea, and the mm > > + * core can't cope with a shared GCS. > > + */ > > + if (vm_flags & (VM_EXEC | VM_ARM64_BTI | VM_SHARED)) > > + return false; > > + } > I wonder whether we should clear VM_MAYEXEC early on during the vma > creation. This way the mprotect() case will be handled in the core code. > 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? > Regarding VM_SHARED, how do we even end up with this via the > map_shadow_stack() syscall? I can't see how one can pass MAP_SHARED to > do_mmap() on this path. I'm fine with a VM_WARN_ON() if you want the > check (and there's no way a user can trigger it). It's just a defenesive programming thing, I'm not aware of any way in which it should be possible to trigger this. > 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. --eyTciqf51C2CbNXu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbDc9MACgkQJNaLcl1U h9DcCAf/aZF31au2O5tCW1iS32zwyPysrbia2QSwmoMPN4cH+zZF6jGKfJP53y/G CNgaoXcyBX2iypaZnICHU23amdDQeA311XwIhP3tEc32tH2i0LgSO39EGLdA4dqe j9An/W7fAj/0GD9s5qxLjEUDr8DKmihD4s/yemH3g2xwf/NF2Ya/tFXJWfAcJPNr rg55UlkNM+WG6bZ21EKnqi/ykDJhHVBdmTEYE7vfyMDjneyhO5oMG6ESXUJFBTd6 JrYRPZb0Cr7QlXE2JRP2yZQG9TzS0WMvsi3TN5T17PRy8WpwtCyfLi3Drj5popSF K/uduuEHbCFXxkFNmqeaOTGvnX2ozA== =Qsdz -----END PGP SIGNATURE----- --eyTciqf51C2CbNXu--