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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1FFF4C2BD09 for ; Tue, 9 Jul 2024 13:07:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VkFT86xjezSo1534g/5yI1hFA5ChsCMa7JV8Mkb8NEY=; b=JnfUCU0yKo0eMCaywxhTcnWUZw zFM7v/zFFkangQA2EcPRAtpZPxhQiWXzQ0fsMw9uts9T+0JieWZDyQ1q08Rx5e9OXxFaRL19JMUE4 4GHq0WCykF6O0E+3TBTU33xBtlLVY8OwKrdnedF5HmUVoXbAAkW9lzb/RD8FX1nA/J0376HH9kBED oiWGSbOv3BttbGAhqjhVUgfxYnX5UEbMH2lBPcsz1FOpfzfM0CbhYaQrFYh+roYqSJmWia56Px04x UlYLJRm/560+7RUoiLmMnZ5GOPO6FBMxT5K3b8gTxLr3r9m4uhU+QKENj3CgjmLg7Nr5G5OnJSW4R rQutqVjA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRAZG-00000007H0y-3KaJ; Tue, 09 Jul 2024 13:07:38 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRAYt-00000007GpJ-1lFU for linux-arm-kernel@lists.infradead.org; Tue, 09 Jul 2024 13:07:16 +0000 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240709_060715_530522_3E184E0B X-CRM114-Status: GOOD ( 15.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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); > +} > +