linux-kernel - [RFC PATCH] remoteproc: core: Do not process carveout and devmem rsc in attach mode

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250724133144.3776839-1-b-padhi@ti.com>
Date: Thu, 24 Jul 2025 19:01:44 +0530
From: Beleswar Padhi <b-padhi@...com>
To: <andersson@...nel.org>, <mathieu.poirier@...aro.org>
CC: <afd@...com>, <hnagalla@...com>, <jm@...com>, <jan.kiszka@...mens.com>,
        <christophe.jaillet@...adoo.fr>, <b-padhi@...com>,
        <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: [RFC PATCH] remoteproc: core: Do not process carveout and devmem rsc in attach mode

When attaching to a remote processor, it is implied that the rproc was
booted by an external entity. Thus, it's carveout and devmem resources
would already have been processed by the external entity during boot.

Re-allocating the carveouts in Linux (without proper flags) would zero
out the memory regions used by the firmware and can lead to undefined
behaviour. And there is no need to re-map the memory regions for devmem
resources as well.

Therefore, do not process the carveout and devmem resources in attach
mode by not appending them to the rproc->carveouts and rproc->mappings
lists respectively.

Signed-off-by: Beleswar Padhi <b-padhi@...com>
---
Testing:
1. Tested IPC with remoteprocs in attach mode in TI platforms.
[However, TI K3 platforms do not use resource table for carveouts,
all the memory regions are reserved statically in Device Tree.]

 drivers/remoteproc/remoteproc_core.c | 30 ++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 825672100528..ef709a5fa73c 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -640,6 +640,20 @@ static int rproc_handle_devmem(struct rproc *rproc, void *ptr,
 		return -EINVAL;
 	}
 
+	/*
+	 * When attaching to a remote processor, it is implied that the rproc
+	 * was booted by an external entity. Thus, it's devmem resources would
+	 * already have been mapped by the external entity during boot. There is
+	 * no need to re-map the memory regions here.
+	 *
+	 * Skip adding the devmem rsc to the mapping list and return without
+	 * complaining.
+	 */
+	if (rproc->state == RPROC_DETACHED) {
+		dev_info(dev, "skipping devmem rsc in attach mode\n");
+		return 0;
+	}
+
 	mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
 	if (!mapping)
 		return -ENOMEM;
@@ -839,6 +853,22 @@ static int rproc_handle_carveout(struct rproc *rproc,
 		return -EINVAL;
 	}
 
+	/*
+	 * When attaching to a remote processor, it is implied that the rproc
+	 * was booted by an external entity. Thus, it's carveout resources would
+	 * already have been allocated by the external entity during boot.
+	 * Re-allocating the carveouts here (without proper flags) would zero
+	 * out the memory regions used by the firmware and can lead to undefined
+	 * behaviour.
+	 *
+	 * Skip adding the carveouts to the alloc list and return without
+	 * complaining.
+	 */
+	if (rproc->state == RPROC_DETACHED) {
+		dev_info(dev, "skipping carveout allocation in attach mode\n");
+		return 0;
+	}
+
 	dev_dbg(dev, "carveout rsc: name: %s, da 0x%x, pa 0x%x, len 0x%x, flags 0x%x\n",
 		rsc->name, rsc->da, rsc->pa, rsc->len, rsc->flags);
 
-- 
2.34.1