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 12B37C282C5 for ; Mon, 3 Mar 2025 12:23:47 +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=VT4MWfspcgTJ3SehDYKVLf6wugc4ps4pfbt0RZrf3Yw=; b=YjrReV+xHEVDsEsdwslA+5PFcS w885FeFqcSSmBjvWSmeHsvucpBDTSz0Y2fYKB3PR5W1iVuqAE/pYfZWQHQNsvF/Mlwq83r6MxVd31 h1bpK3SDJX7kEu653Gu3g8xCbmEZwo1izL6TMOHZX0XMAgbxt0+V4ibSQmWQ5YUpM9+WG9ITO6l7Y DpmbFc0dVTqMKbbtHI8RHAOLFhBnqzVwtFhrH/iJmIpbe898I+aYaGc0Wb1ffck0LtkILh3N/6tKP 11cbgXnu4xFj4Ay98s25HpXhRSYHRUOrI76j+N49RS4hTgF6IQ2Xv6mHLSyfTo+tWmOl5vSukf9wq rosYDQsQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tp4pc-00000000jdI-1hxr; Mon, 03 Mar 2025 12:23:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tp44z-00000000aSW-0dpf for linux-arm-kernel@lists.infradead.org; Mon, 03 Mar 2025 11:35:26 +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 654ED1063; Mon, 3 Mar 2025 03:35:36 -0800 (PST) Received: from [10.57.37.67] (unknown [10.57.37.67]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 111383F673; Mon, 3 Mar 2025 03:35:19 -0800 (PST) Message-ID: <2b6d5287-bdea-4ec3-a07f-986bd3c3b285@arm.com> Date: Mon, 3 Mar 2025 11:35:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/3] arm64: realm: Fix DMA address for devices Content-Language: en-GB To: linux-kernel@vger.kernel.org, Marek Szyprowski Cc: will@kernel.org, catalin.marinas@arm.com, maz@kernel.org, steven.price@arm.com, aneesh.kumar@kernel.org, gshan@redhat.com, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org, Jean-Philippe Brucker , Christoph Hellwig , Marek Szyprowski , Tom Lendacky References: <20250227144150.1667735-1-suzuki.poulose@arm.com> From: Suzuki K Poulose In-Reply-To: <20250227144150.1667735-1-suzuki.poulose@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250303_033525_286506_57BAF5DB X-CRM114-Status: GOOD ( 35.00 ) 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 Hi Marek, On 27/02/2025 14:41, Suzuki K Poulose wrote: > Linux can be run as a Confidential Guest in Arm CCA from Linux v6.13. The address > space (GPA or IPA) of a Realm VM is split into two halves, with private bottom > half and shared top half. In Linux we treat the "top" bit of the IPA space as > an attribute, to indicate whether it is shared or not (MSB == 1 implies shared). > Stage2 (GPA to PA) translations used by the CPU accesses, cover the full IPA space, > and are managed by RMM. The "top" bit as attribute is only a software construct. > > At present any device passed through to a Realm is treated as untrusted and the > Realm uses bounce buffering for any DMA, using the "decrypted" (shared) DMA > buffers (i.e., IPA with top bit set). In Linux, we only send the "DMA" address > masking the "top" bit. In Arm CCA, SMMU for untrusted devices are managed by the > non-secure Host and thus it can be confusing for the host/device when an unmasked > address is provided. Given there could be other hypervisors than Linux/KVM > running Arm CCA guests, the Realm Guest must adhere to a single convention for > the DMA address. This gets further complicated when we add support for trusted > devices, which can DMA into the full Realm memory space, once accepted. Thus, > a DMA masked address (with "top" bit lost) will prevent a trusted device from > accessing a shared buffer. > > To resolve this Arm has decided to standardise the DMA address used by the Realm > to include the full IPA address bits (including the "top" bit, which Linux uses > as an attribute). This implies, any DMA to a shared buffer must have the top bit > of the IPA space set. > > There is already a provision to do this in phys_to_dma* and dma_to_phys(), but > that is specific to AMD SME and is quite the opposite of what we need for Arm CCA. > i.e., For Arm CCA we need to set the bit for "decrypted" DMA and clear the bit > for "encrypted". > > This series converts the existing __sme_* helpers to a bit more generalised versions : > dma_addr_decrypted() and dma_encrypted(). Also, while converting a DMA address back > to CPU physical address requires clearing off any "encryption/decryption" bits. > I have named this "dma_addr_canonical()". (The other options are : > * dma_addr_clear_encryption - Well, not just for encryption, but we clear decryption > too, so not ideal. > * dma_addr_normal > * dma_addr_clear > * dma_addr_default > > This also implies that the VMMs must take care to : > > 1. Create the S2-SMMU mappings for VFIO at the "unprotected" alias. > 2. Always mask the "top" bit off any IPA it receives from the Realm for DMA. > KVM already does that today and no changes are required. > > A kvmtool branch with the changes above is available here [1]. There are two > patches [2] & [3], that are really required on top of the Arm CCA support. > > Ideally it would be good to get this backported to v6.13 stable kernel releases > to make sure that they are compliant with this change. > Please could you take a look at this series and let us know your thoughts ? If you are happy with the changes, are you happy to pull this through the DMA MAP tree ? The relevant bits have been reviewed/ acked by people (arm64 and AMD bits). Kind regards Suzuki > Changes since v2: > Link: https://lkml.kernel.org/r/20250219220751.1276854-1-suzuki.poulose@arm.com > - Collect Acks & Reviews for Patch 1 > - Rename helpers > dma_encrypted => dma_addr_encrypted > dma_decrypted => dma_addr_unencrypted > dma_clear_encryption => dma_addr_canonical > - For Arm CCA, use PROT_NS_SHARED, set/clear only the top IPA bit. > - Drop dma_addr_encrypted() helper for Arm CCA as it is a NOP > > Changes since v1 > Link: https://lkml.kernel.org/r/20250212171411.951874-1-suzuki.poulose@arm.com > - Follow Robin's suggestion to generalise the DMA address conversion helpers > to provide dma_{encrypte,decrypted,clear_encryption}. See PATCH 2 for more > details. > - Add a fix to the ordering of "__sme_clr" for dma_to_phys (PATCH 1) > > [1] git@git.gitlab.arm.com:linux-arm/kvmtool-cca.git cca/guest-dma-alias/v1 > [2] https://gitlab.arm.com/linux-arm/kvmtool-cca/-/commit/ea37a6eb968abe4c75be4a8a90808714657c2ef7 > [3] https://gitlab.arm.com/linux-arm/kvmtool-cca/-/commit/8afd0d5e6a7ee444dd0c1565fe94ecd831054a29 > > Cc: Will Deacon > Cc: Jean-Philippe Brucker > Cc: Catalin Marinas > Cc: Robin Murphy > Cc: Steven Price > Cc: Christoph Hellwig > Cc: Marek Szyprowski > Cc: Tom Lendacky > Cc: Gavin Shan > > Suzuki K Poulose (3): > dma: Fix encryption bit clearing for dma_to_phys > dma: Introduce generic dma_addr_*crypted helpers > arm64: realm: Use aliased addresses for device DMA to shared buffers > > arch/arm64/include/asm/mem_encrypt.h | 11 +++++++++++ > include/linux/dma-direct.h | 13 +++++++++---- > include/linux/mem_encrypt.h | 23 +++++++++++++++++++++++ > 3 files changed, 43 insertions(+), 4 deletions(-) >