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 D1842C25B7A for ; Fri, 17 May 2024 09:34:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1/hP1UD/+Ogf8gWKYceI+XRGxBgP+Esu9E3Pj2UcIM4=; b=nuoawS8fxvcmcr yhBEshZE30jaZhqJEQ2L/TfcV7n5Ox8GLxE9rMdznl31/CtrKkvilwFC32vT5ORWn0O2eFtu2IYvP mf8qk5rV1TPrXZV/Yg/pbTRr7euET4AkqVbqKUNOPZibaHqDnQORvqCvZvO2bb28RSf2DHLxpWW8U pr0Ri6zeLIjnLlL+1694W5yH325ilNcA0s6XZveFwv7wGjv3VCZpmG5+F6f8MxhIWuKFnECsylK6v d7CaSjrYLyojygbZJ1z4lxqLR3mJv76HPH/Y2Q0VIKBB+LT4+pnciVjGHYKNF3ITaOFtdJpFdhyVB tNHWeEIOwYR2705LoQQQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7tyh-00000007NCa-0mAB; Fri, 17 May 2024 09:34:15 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7tye-00000007NAN-1ca6 for linux-arm-kernel@lists.infradead.org; Fri, 17 May 2024 09:34:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 18D31CE1A20; Fri, 17 May 2024 09:34:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2945C32786; Fri, 17 May 2024 09:34:02 +0000 (UTC) Date: Fri, 17 May 2024 10:34:00 +0100 From: Catalin Marinas To: Suzuki K Poulose Cc: Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev, Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni Subject: Re: [PATCH v2 10/14] arm64: Force device mappings to be non-secure shared Message-ID: References: <20240412084213.1733764-1-steven.price@arm.com> <20240412084213.1733764-11-steven.price@arm.com> <4e89f047-ae70-43a8-a459-e375ca05b2c2@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4e89f047-ae70-43a8-a459-e375ca05b2c2@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240517_023412_883923_F6B5B0BD X-CRM114-Status: GOOD ( 31.82 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 15, 2024 at 12:00:49PM +0100, Suzuki K Poulose wrote: > On 15/05/2024 10:01, Catalin Marinas wrote: > > On Fri, Apr 12, 2024 at 09:42:09AM +0100, Steven Price wrote: > > > From: Suzuki K Poulose > > > > > > Device mappings (currently) need to be emulated by the VMM so must be > > > mapped shared with the host. > > > > You say "currently". What's the plan when the device is not emulated? > > How would the guest distinguish what's emulated and what's not to avoid > > setting the PROT_NS_SHARED bit? > > Arm CCA plans to add support for passing through real devices, > which support PCI-TDISP protocol. This would involve the Realm > authenticating the device and explicitly requesting "protected" > mapping *after* the verification (with the help of RMM). I'd have to do some reading, no clue how this works. > > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > > > index f5376bd567a1..db71c564ec21 100644 > > > --- a/arch/arm64/include/asm/pgtable.h > > > +++ b/arch/arm64/include/asm/pgtable.h > > > @@ -598,7 +598,7 @@ static inline void set_pud_at(struct mm_struct *mm, unsigned long addr, > > > #define pgprot_writecombine(prot) \ > > > __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN) > > > #define pgprot_device(prot) \ > > > - __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN) > > > + __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN | PROT_NS_SHARED) > > > > This pgprot_device() is not the only one used to map device resources. > > pgprot_writecombine() is another commonly macro. It feels like a hack to > > plug one but not the other and without any way for the guest to figure > > out what's emulated. > > Agree. I have been exploring hooking this into ioremap_prot() where we > could apply the attribute accordingly. We will change it in the next > version. pgprot_* at least has the advantage that it covers other places. ioremap_prot() would handle the kernel mappings but you have devices mapped in user-space via remap_pfn_range() for example. The protection bits may come from dma_pgprot() with either write-combine or cacheable attributes. One may map device I/O as well (not sure what DPDK does). We could restrict those to protected devices but we need to go through the use-cases. All this needs some thinking, especially if at some point we'll have protected devices. Just hijacking the low-level pgprot macros doesn't feel like a great approach. > > Can the DT actually place those emulated ranges in the higher IPA space > > so that we avoid randomly adding this attribute for devices? > > It can, but then we kind of break the "Realm" view of the IPA space. i.e., > right now it only knows about the "lower IPA" half and uses the top bit as a > protection attr to access the IPA as shared. > > Expanding IPA size view kind of breaks "sharing memory", where, we > must "use a different PA" for a page that is now shared. True, I did not realise that the IPA split is transparent to the host. An option would be additional DT/ACPI attributes for those devices. That's not great either though as we can't handle those attributes in the arch code only and probably we don't want to change generic drivers. Yet another option would be to query the RMM somehow. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel