linux-kernel - [PATCH v2] firmware: qcom_scm: Add a padded page to ensure DMA memory from lower 4GB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Fri, 24 May 2024 21:01:45 +0530
From: Mukesh Ojha <quic_mojha@...cinc.com>
To: <andersson@...nel.org>, <konrad.dybcio@...aro.org>
CC: <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        "Mukesh
 Ojha" <quic_mojha@...cinc.com>
Subject: [PATCH v2] firmware: qcom_scm: Add a padded page to ensure DMA memory from lower 4GB

For SCM protection, memory allocation should be physically contiguous,
4K aligned, and non-cacheable to avoid XPU violations. This granularity
of protection applies from the secure world. Additionally, it's possible
that a 32-bit secure peripheral will access memory in SoCs like
sm8{4|5|6}50 for some remote processors. Therefore, memory allocation
needs to be done in the lower 4 GB range. To achieve this, Linux's CMA
pool can be used with dma_alloc APIs.

However, dma_alloc APIs will fall back to the buddy pool if the requested
size is less than or equal to PAGE_SIZE. It's also possible that the remote
processor's metadata blob size is less than a PAGE_SIZE. Even though the
DMA APIs align the requested memory size to PAGE_SIZE, they can still fall
back to the buddy allocator, which may fail if `CONFIG_ZONE_{DMA|DMA32}`
is disabled.

To address this issue, use an extra page as padding to ensure allocation
from the CMA region. Since this memory is temporary, it will be released
once the remote processor is up or in case of any failure.

Signed-off-by: Mukesh Ojha <quic_mojha@...cinc.com>
---
Changes in v2:
 - Described the issue more clearly in commit text.

 drivers/firmware/qcom/qcom_scm.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 520de9b5633a..0426972178a4 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -538,6 +538,7 @@ static void qcom_scm_set_download_mode(bool enable)
 int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size,
 			    struct qcom_scm_pas_metadata *ctx)
 {
+	size_t page_aligned_size;
 	dma_addr_t mdata_phys;
 	void *mdata_buf;
 	int ret;
@@ -555,7 +556,8 @@ int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size,
 	 * data blob, so make sure it's physically contiguous, 4K aligned and
 	 * non-cachable to avoid XPU violations.
 	 */
-	mdata_buf = dma_alloc_coherent(__scm->dev, size, &mdata_phys,
+	page_aligned_size = PAGE_ALIGN(size + PAGE_SIZE);
+	mdata_buf = dma_alloc_coherent(__scm->dev, page_aligned_size, &mdata_phys,
 				       GFP_KERNEL);
 	if (!mdata_buf) {
 		dev_err(__scm->dev, "Allocation of metadata buffer failed.\n");
@@ -580,11 +582,11 @@ int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size,

 out:
 	if (ret < 0 || !ctx) {
-		dma_free_coherent(__scm->dev, size, mdata_buf, mdata_phys);
+		dma_free_coherent(__scm->dev, page_aligned_size, mdata_buf, mdata_phys);
 	} else if (ctx) {
 		ctx->ptr = mdata_buf;
 		ctx->phys = mdata_phys;
-		ctx->size = size;
+		ctx->size = page_aligned_size;
 	}

 	return ret ? : res.result[0];
-- 
2.7.4