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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIjqBi3X4hWGsJLP@p14s>
Date: Tue, 29 Jul 2025 09:34:30 -0600
From: Mathieu Poirier <mathieu.poirier@...aro.org>
To: Beleswar Padhi <b-padhi@...com>
Cc: andersson@...nel.org, afd@...com, hnagalla@...com, jm@...com,
	jan.kiszka@...mens.com, christophe.jaillet@...adoo.fr,
	linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
	daniel.baluta@....com, iuliana.prodan@....com,
	arnaud.pouliquen@...s.st.com, tanmay.shah@....com
Subject: Re: [RFC PATCH] remoteproc: core: Do not process carveout and devmem
 rsc in attach mode

Hi Beleswar,

On Thu, Jul 24, 2025 at 07:01:44PM +0530, Beleswar Padhi wrote:
> 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.
> 

I think what you are proposing is logical.  Arnaud, Daniel, Iuliana and Tanmay -
please test this on your platforms.  I will also need another TB from someone at
TI.

Regards,
Mathieu

> 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
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ