From nobody Thu Dec 18 16:18:42 2025 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 74D5D235341 for ; Wed, 19 Feb 2025 22:09:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740002979; cv=none; b=git6Hh7w52pOOlymSqMDm8vhc4N1C+Sfv/4TPdJVifeQwOR5X9ECIlfxlcKOKYcE/XtnuL3dEqfRUu3JonqSapn7iSlUrov+pfWvWJjhdDvr5OkzQXf3DJqT/qcT42qG+5b+gDi9es2D4o1kfdbGlfa+xpGbvLu/oshlJJaOtjE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740002979; c=relaxed/simple; bh=4iMOmaLbt8kCVoGpJtn+wXCpd4nNqDG6hAArQ/zlzR8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gid2cxmiI9c4mwVO9SGYnXz6eihmggCF5rJMYNHQx6UOA4R7riODlAFEDCn1jBiVktHc92n+5sTfeawBG8AnZU6bi5YJmNAHF9z69fg/cZgFmuvnUahM2p1GJPNQhLC5V+v8+2dAkMXTqcHio2FG93oLCwqSIKVyNdQ+qS6w2pI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 E74EA153B; Wed, 19 Feb 2025 14:09:55 -0800 (PST) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 0B9793F6A8; Wed, 19 Feb 2025 14:09:35 -0800 (PST) From: Suzuki K Poulose To: will@kernel.org, robin.murphy@arm.com, catalin.marinas@arm.com Cc: maz@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, aneesh.kumar@kernel.org, steven.price@arm.com, suzuki.poulose@arm.com, Jean-Philippe Brucker , Christoph Hellwig , Tom Lendacky Subject: [PATCH v2 1/3] dma: Fix encryption bit clearing for dma_to_phys Date: Wed, 19 Feb 2025 22:07:49 +0000 Message-ID: <20250219220751.1276854-2-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250219220751.1276854-1-suzuki.poulose@arm.com> References: <20250219220751.1276854-1-suzuki.poulose@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" phys_to_dma() sets the encryption bit on the translated DMA address. But dma_to_phys() clears the encryption bit after it has been translated back to the physical address, which could fail if the device uses DMA ranges. Hopefully, AMD SME doesn't use it. Anyways, let us fix it, before cleanup the infrastructure for supporting other architectures. Reported-by: Aneesh Kumar K.V Link: https://lkml.kernel.org/r/yq5amsen9stc.fsf@kernel.org Cc: Will Deacon Cc: Jean-Philippe Brucker Cc: Catalin Marinas Cc: Robin Murphy Cc: Steven Price Cc: Christoph Hellwig Cc: Tom Lendacky Signed-off-by: Suzuki K Poulose Acked-by: Tom Lendacky Reviewed-by: Robin Murphy --- include/linux/dma-direct.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index d7e30d4f7503..d20ecc24cb0f 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -101,12 +101,13 @@ static inline phys_addr_t dma_to_phys(struct device *= dev, dma_addr_t dma_addr) { phys_addr_t paddr; =20 + dma_addr =3D __sme_clr(dma_addr); if (dev->dma_range_map) paddr =3D translate_dma_to_phys(dev, dma_addr); else paddr =3D dma_addr; =20 - return __sme_clr(paddr); + return paddr; } #endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */ =20 --=20 2.43.0 From nobody Thu Dec 18 16:18:42 2025 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 175932586D8 for ; Wed, 19 Feb 2025 22:09:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740002981; cv=none; b=gPTJ6HEws69mlV9y8MapzoQKEc0orOHMMWOViKKidpc6rM81rowDuv+YqX5kf722Jqc5LAkVTsKCHnrRKAIUX8NReJM4fkuYFtGY6NHuWlF9eXvq5RCBUvPyO4rp2tpiCRdLNqxdcsb6ANTV07x5nizlH/Ly/6NA82kGLe+YHeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740002981; c=relaxed/simple; bh=LZiM/rdW7XeXRPfAUGBlEYO6/j16zSj8soDjaY+L7k8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l/iWURsQ3seOqu/LnTCzptKbesmS2TiavBq7Enl1lckGPyoI/BQe28JRXqjIDL3Eett84fML3PBfT26+eYJxeR8Kx0yHZclLFmunlMw1En2K/MeUEYNoxkjF8vdMqQ5/oGgGOvqN7JRNWFFGOJAxrOM2fL+4mDPA0FqbnnTNd+8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 BA64B1595; Wed, 19 Feb 2025 14:09:57 -0800 (PST) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id D106D3F6A8; Wed, 19 Feb 2025 14:09:37 -0800 (PST) From: Suzuki K Poulose To: will@kernel.org, robin.murphy@arm.com, catalin.marinas@arm.com Cc: maz@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, aneesh.kumar@kernel.org, steven.price@arm.com, suzuki.poulose@arm.com, Jean-Philippe Brucker , Christoph Hellwig , Tom Lendacky Subject: [PATCH v2 2/3] dma: Introduce generic dma_decrypted/dma_encrypted helpers Date: Wed, 19 Feb 2025 22:07:50 +0000 Message-ID: <20250219220751.1276854-3-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250219220751.1276854-1-suzuki.poulose@arm.com> References: <20250219220751.1276854-1-suzuki.poulose@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" AMD SME added __sme_set/__sme_clr primitives to modify the DMA address for encrypted/decrypted traffic. However this doesn't fit in with other models, e.g., Arm CCA where the meanings are the opposite. i.e., "decrypted" traffic has a bit set and "encrypted" traffic has the top bit cleared. In preparation for adding the support for Arm CCA DMA conversions, convert = the existing primitives to more generic ones that can be provided by the backen= ds. i.e., add helpers to 1. dma_encrypted - Convert a DMA address to "encrypted" [ =3D=3D __sme_set= () ] 2. dma_decrypted - Convert a DMA address to "decrypted" [ None exists toda= y ] 3. dma_clear_encryption - Clear any "encryption"/"decryption" bits from DMA address [ SME uses __sme_clr() ] Since the original __sme_xxx helpers come from linux/mem_encrypt.h, use that as the home for the new definitions and provide dummy ones when none is pro= vided by the architectures. With the above, phys_to_dma_unencrypted() uses the newly added dma_decrypte= d() helper and to make it a bit more easier to read and avoid double conversion, provide __phys_to_dma(). No functional changes intended. Compile tested on x86 defconfig with CONFIG_AMD_MEM_ENCRYPT. Suggested-by: Robin Murphy Cc: Will Deacon Cc: Jean-Philippe Brucker Cc: Catalin Marinas Cc: Robin Murphy Cc: Steven Price Cc: Christoph Hellwig Cc: Tom Lendacky Cc: Aneesh Kumar K.V Signed-off-by: Suzuki K Poulose --- include/linux/dma-direct.h | 12 ++++++++---- include/linux/mem_encrypt.h | 23 +++++++++++++++++++++++ 2 files changed, 31 insertions(+), 4 deletions(-) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index d20ecc24cb0f..9b5cc0ee86d5 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -78,14 +78,18 @@ static inline dma_addr_t dma_range_map_max(const struct= bus_dma_region *map) #define phys_to_dma_unencrypted phys_to_dma #endif #else -static inline dma_addr_t phys_to_dma_unencrypted(struct device *dev, - phys_addr_t paddr) +static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pad= dr) { if (dev->dma_range_map) return translate_phys_to_dma(dev, paddr); return paddr; } =20 +static inline dma_addr_t phys_to_dma_unencrypted(struct device *dev, + phys_addr_t paddr) +{ + return dma_decrypted(__phys_to_dma(dev, paddr)); +} /* * If memory encryption is supported, phys_to_dma will set the memory encr= yption * bit in the DMA address, and dma_to_phys will clear it. @@ -94,14 +98,14 @@ static inline dma_addr_t phys_to_dma_unencrypted(struct= device *dev, */ static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr) { - return __sme_set(phys_to_dma_unencrypted(dev, paddr)); + return dma_encrypted(__phys_to_dma(dev, paddr)); } =20 static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_a= ddr) { phys_addr_t paddr; =20 - dma_addr =3D __sme_clr(dma_addr); + dma_addr =3D dma_clear_encryption(dma_addr); if (dev->dma_range_map) paddr =3D translate_dma_to_phys(dev, dma_addr); else diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h index ae4526389261..c8dcc1be695a 100644 --- a/include/linux/mem_encrypt.h +++ b/include/linux/mem_encrypt.h @@ -26,11 +26,34 @@ */ #define __sme_set(x) ((x) | sme_me_mask) #define __sme_clr(x) ((x) & ~sme_me_mask) + +#define dma_encrypted(x) __sme_set(x) +#define dma_clear_encryption(x) __sme_clr(x) + #else #define __sme_set(x) (x) #define __sme_clr(x) (x) #endif =20 +/* + * dma_encrypted() and dma_decrypted() are for converting a given DMA + * address to the respective type of addressing. + * + * dma_clear_encryption() is used to reverse the conversion back to "norma= l" + * DMA address. + */ +#ifndef dma_encrypted +#define dma_encrypted(x) (x) +#endif + +#ifndef dma_decrypted +#define dma_decrypted(x) (x) +#endif + +#ifndef dma_clear_encryption +#define dma_clear_encryption(x) (x) +#endif + #endif /* __ASSEMBLY__ */ =20 #endif /* __MEM_ENCRYPT_H__ */ --=20 2.43.0 From nobody Thu Dec 18 16:18:42 2025 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C999B25A2C4 for ; Wed, 19 Feb 2025 22:09:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740002983; cv=none; b=IAfLtlikm9TEfSQ0Ah9tzPfDGeuP4SqwNdI1e2TrXnAGtCcqKI3q9zYCZhWe9jd19UE+u7FurQVM2/rMIAtkgoHNr9uPOVu022sh1AEzS9Fu6jUVaON+5QO5b6u8irdQnxEBGXDHL8BwXx2K/GwKl6wkcVCaG4yrd5QrfcbPK3g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740002983; c=relaxed/simple; bh=82rdocLjg7bYXR3a/TcdwqXAYcr+mVrMdClya9NXNxc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h73xmr/om1Gp5VPGFpYjNXBBO3/zT52KzSpZu0TvfstbW7KOn6BwG8Jmnlz3on+Q6psvQfF0GYHLM4+lQPE+gbwibuTJ+d3h8fj2lDpranUmywS60rViBWbEUc9NSNOtnjqqkxi0vH4moSnFPdnAupEglaQ4tJhCtHtR0cc+E7k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 8989B153B; Wed, 19 Feb 2025 14:09:59 -0800 (PST) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id A20153F6A8; Wed, 19 Feb 2025 14:09:39 -0800 (PST) From: Suzuki K Poulose To: will@kernel.org, robin.murphy@arm.com, catalin.marinas@arm.com Cc: maz@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, aneesh.kumar@kernel.org, steven.price@arm.com, suzuki.poulose@arm.com, Jean-Philippe Brucker , Christoph Hellwig , Tom Lendacky Subject: [PATCH v2 3/3] arm64: realm: Use aliased addresses for device DMA to shared buffers Date: Wed, 19 Feb 2025 22:07:51 +0000 Message-ID: <20250219220751.1276854-4-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250219220751.1276854-1-suzuki.poulose@arm.com> References: <20250219220751.1276854-1-suzuki.poulose@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When a device performs DMA to a shared buffer using physical addresses, (without Stage1 translation), the device must use the "{I}PA address" with = the top bit set in Realm. This is to make sure that a trusted device will be ab= le to write to shared buffers as well as the protected buffers. Thus, a Realm = must always program the full address including the "protection" bit, like AMD SME encryption bits. Enable this by providing arm64 specific dma_{encrypted,decrypted,clear_encr= yption} helpers for Realms. Please note that the VMM needs to similarly make sure t= hat the SMMU Stage2 in the Non-secure world is setup accordingly to map IPA at = the unprotected alias. Cc: Will Deacon Cc: Jean-Philippe Brucker Cc: Catalin Marinas Cc: Robin Murphy Cc: Steven Price Cc: Christoph Hellwig Cc: Tom Lendacky Cc: Aneesh Kumar K.V Signed-off-by: Suzuki K Poulose --- arch/arm64/include/asm/mem_encrypt.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/arm64/include/asm/mem_encrypt.h b/arch/arm64/include/asm/= mem_encrypt.h index f8f78f622dd2..aeda3bba255e 100644 --- a/arch/arm64/include/asm/mem_encrypt.h +++ b/arch/arm64/include/asm/mem_encrypt.h @@ -21,4 +21,26 @@ static inline bool force_dma_unencrypted(struct device *= dev) return is_realm_world(); } =20 +static inline dma_addr_t dma_decrypted(dma_addr_t daddr) +{ + if (is_realm_world()) + daddr |=3D prot_ns_shared; + return daddr; +} +#define dma_decrypted dma_decrypted + +static inline dma_addr_t dma_encrypted(dma_addr_t daddr) +{ + if (is_realm_world()) + daddr &=3D prot_ns_shared - 1; + return daddr; +} +#define dma_encrypted dma_encrypted + +static inline dma_addr_t dma_clear_encryption(dma_addr_t daddr) +{ + return dma_encrypted(daddr); +} +#define dma_clear_encryption dma_clear_encryption + #endif /* __ASM_MEM_ENCRYPT_H */ --=20 2.43.0