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 9C367C2BD09 for ; Tue, 9 Jul 2024 13:07:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 307E06B0082; Tue, 9 Jul 2024 09:07:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 291E16B009C; Tue, 9 Jul 2024 09:07:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 113986B009D; Tue, 9 Jul 2024 09:07:18 -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 E0CA66B0082 for ; Tue, 9 Jul 2024 09:07:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6E7D1418F3 for ; Tue, 9 Jul 2024 13:07:17 +0000 (UTC) X-FDA: 82320240114.08.3C758A9 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf19.hostedemail.com (Postfix) with ESMTP id 891441A0019 for ; Tue, 9 Jul 2024 13:07:15 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of kevin.brodsky@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=kevin.brodsky@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720530395; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VkFT86xjezSo1534g/5yI1hFA5ChsCMa7JV8Mkb8NEY=; b=WXJIvmFcJMGpnRQusNqLiqkcUMuj2HHyekQJ6SbsTp+clCtfq8j444Z6Nrmz7jEIpPXIpk vedCl6pP5ADt4VqkSeRdp6F+mv3rOnCjeFOQD+tz1TLeyWPGa6TLc6ms9wcbMLv2mGmN8Z 1rafZS/zLA67eZ/5NlM8APWeRNhxO7w= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of kevin.brodsky@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=kevin.brodsky@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720530395; a=rsa-sha256; cv=none; b=vaQLOWzVu+2YV0N/2K+ORUyvEDZsi5HBEhmUStsKfX2F9nzJWLTm46SA3Zc/xfJEbVwAeh S1zHvf34FEPM2Kzx3/AvZWoGgAnR5kfhYj0VzvD9tpRsLcCPHwt6T8gXP4AdMFKLOrXIwX mek7HgJJTbEfk09AkUPR9cp/EujMonM= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B393F1650; Tue, 9 Jul 2024 06:07:39 -0700 (PDT) Received: from [10.44.160.75] (e126510-lin.lund.arm.com [10.44.160.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9F1823F766; Tue, 9 Jul 2024 06:07:08 -0700 (PDT) Message-ID: <18aee949-7e07-45e1-85c8-c990f017f305@arm.com> Date: Tue, 9 Jul 2024 15:07:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 17/29] arm64: implement PKEYS support To: Joey Gouly , linux-arm-kernel@lists.infradead.org Cc: akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, bp@alien8.de, broonie@kernel.org, catalin.marinas@arm.com, christophe.leroy@csgroup.eu, dave.hansen@linux.intel.com, hpa@zytor.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au, naveen.n.rao@linux.ibm.com, npiggin@gmail.com, oliver.upton@linux.dev, shuah@kernel.org, szabolcs.nagy@arm.com, tglx@linutronix.de, will@kernel.org, x86@kernel.org, kvmarm@lists.linux.dev References: <20240503130147.1154804-1-joey.gouly@arm.com> <20240503130147.1154804-18-joey.gouly@arm.com> Content-Language: en-GB From: Kevin Brodsky In-Reply-To: <20240503130147.1154804-18-joey.gouly@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 891441A0019 X-Stat-Signature: o4j8zt7zha9x8j86yyy19ducnotg5ksa X-Rspam-User: X-HE-Tag: 1720530435-878409 X-HE-Meta: U2FsdGVkX1+OhMTIeplh2C4NUUktAnggcI1td9hZPJjMXCVNkuADRIO6P+o1DhNWBCfYzVEi3YkjOQgJlBIw6pxNwYLDursFq7OeOUrc2jrZwp9+FRloeY4lQx9PbSoSoCLJK4zUMjLxWAdMCwGnGZQVhZv7a61UVK/iwbKLXRIja+dIvayVta5YAcslFKsDd3r9C8oxZUSkGD/t2OxyZmaoWSdnSYHNuJiIB1V5DQII06mA6kWG3OdhGnHvp2i77BYU07UAKF3JAotCmyfXSCJw/kp3uB0uvGgNnUHcv6Ot7XvcrGsXFhvdbVijWuSEWEZKoDYU7401ilvpBmZz6rekHtlQk/mqBdfhIU0+F3HxPGELbHCI48FE+hmBYAdIshC3NosKLni+tCfTxfgLJdIb8QfKQ13P6UKviGtBqR4ASy6mDvtDuv5lbr3gVoxK+rzSzX2spm0dNgNga0AU8cHp7HO7TZ9UrzEKDVUbfVuqvrTDYjW9MMzuU5cPgJAE39zAV4KIqOvg1X9aO/gO02BbueTCl9qryUooEnBn63Il86MdJ5GGxYh1gb6WB+BAwEqwDwCrMLhxG8h5M6QLdRrAOPoq7mvILzMC0gyHgVywzvkcSBFR5ozKlEX+u/LqXrkqmjP6l+tNUz2HVpvjSt1LxD/4KQ9ZSnbYyHwOGUkIE9n7Z2iBEOumwveVg1zyd/WnwwIjAj9TlT+wWKegfaJIrycFFs/U45yD0lvOxLtO1TyIwe2OqI0ArgovoiarS/60x4tjO+pIjuiY2K7QU/bx+KBjz8GBm4+KXyZFF4TZOyfFJQc/YM8wj+b750UjXH0tO3HQ45/FAZHhEQ4+/MWxV2attHdWkyePlc9BSag4kSLC7vsWH8oVO/AJeb5CYCkemX+WfDb8O0M3JjHNMkBByizDyzbIpcVnmY1RoVBOk9CpQsYkWq06kE0tKwFki/0QRKvm8DtEjvJZ84N Be3WwVDC SUWDO3xsN+dQaDW8t81+MYDCestO/B4tuMoc5g3zs1qStjrX27Cq62sl7rmNd9x0fvyl87aITMSwftsSogG+o8OrykjhFuyaAfIRWrYbVOV3XPSiXQJ+GfHNKXnqcyh1OOU8vqG0U+Ag3pJvWfrOmFupCkw== 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: On 03/05/2024 15:01, Joey Gouly wrote: > @@ -267,6 +294,28 @@ static inline unsigned long mm_untag_mask(struct mm_struct *mm) > return -1UL >> 8; > } > > +/* > + * We only want to enforce protection keys on the current process > + * because we effectively have no access to POR_EL0 for other > + * processes or any way to tell *which * POR_EL0 in a threaded > + * process we could use. I see that this comment is essentially copied from x86, but to me it misses the main point. Even with only one thread in the target process and a way to obtain its POR_EL0, it still wouldn't make sense to check that value. If we take the case of a debugger accessing an inferior via ptrace(), for instance, the kernel is asked to access some memory in another mm. However, the debugger's POR_EL0 is tied to its own address space, and the target's POR_EL0 is relevant to its own execution flow only. In such situations, there is essentially no user context for the access, so It fundamentally does not make sense to make checks based on pkey/POE or similar restrictions to memory accesses (e.g. MTE). Kevin > + * > + * So do not enforce things if the VMA is not from the current > + * mm, or if we are in a kernel thread. > + */ > +static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, > + bool write, bool execute, bool foreign) > +{ > + if (!arch_pkeys_enabled()) > + return true; > + > + /* allow access if the VMA is not one from this process */ > + if (foreign || vma_is_foreign(vma)) > + return true; > + > + return por_el0_allows_pkey(vma_pkey(vma), write, execute); > +} > +