linux-kernel - Re: [PATCH 1/7] amp/remoteproc: add framework for controlling remote processors

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120103233534.GC2492@ponder.secretlab.ca>
Date:	Tue, 3 Jan 2012 16:35:34 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
	Brian Swetland <swetland@...gle.com>,
	Arnd Bergmann <arnd@...db.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Tony Lindgren <tony@...mide.com>,
	Russell King <linux@....linux.org.uk>,
	Greg KH <greg@...ah.com>, Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: [PATCH 1/7] amp/remoteproc: add framework for controlling remote
 processors

On Tue, Oct 25, 2011 at 11:48:20AM +0200, Ohad Ben-Cohen wrote:
> Modern SoCs typically employ a central symmetric multiprocessing (SMP)
> application processor running Linux, with several other asymmetric
> multiprocessing (AMP) heterogeneous processors running different instances
> of operating system, whether Linux or any other flavor of real-time OS.
> 
> Booting a remote processor in an AMP configuration typically involves:
> - Loading a firmware which contains the OS image
> - Allocating and providing it required system resources (e.g. memory)
> - Programming an IOMMU (when relevant)
> - Powering on the device
> 
> This patch introduces a generic framework that allows drivers to do
> that. In the future, this framework will also include runtime power
> management and error recovery.
> 
> Based on (but now quite far from) work done by Fernando Guzman Lugo
> <fernando.lugo@...com>.
[...]
> +static int rproc_load_segments(struct rproc *rproc, const u8 *elf_data)
> +{
> +	struct device *dev = rproc->dev;
> +	struct elf32_hdr *ehdr;
> +	struct elf32_phdr *phdr;
> +	int i, ret = 0;
> +
> +	ehdr = (struct elf32_hdr *)elf_data;
> +	phdr = (struct elf32_phdr *)(elf_data + ehdr->e_phoff);
> +
> +	/* go through the available ELF segments */
> +	for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
> +		u32 da = phdr->p_paddr;
> +		u32 memsz = phdr->p_memsz;
> +		u32 filesz = phdr->p_filesz;

This could be an endianess problem.  If the endianess of the host and
the rproc are different, then what is the endianess of the elf file?
Is the endianess of the elf file verified before attempting to parse it?

> +/* handle firmware resource entries before booting the remote processor */
> +static int
> +rproc_handle_boot_rsc(struct rproc *rproc, struct fw_resource *rsc, int len)
> +{
> +	struct device *dev = rproc->dev;
> +	int ret = 0;
> +
> +	while (len >= sizeof(*rsc)) {
> +		dev_dbg(dev, "rsc: type %d, da 0x%llx, pa 0x%llx, len 0x%x, "
> +			"id %d, name %s, flags %x\n", rsc->type, rsc->da,
> +			rsc->pa, rsc->len, rsc->id, rsc->name, rsc->flags);
> +
> +		switch (rsc->type) {
> +		case RSC_CARVEOUT:
> +			ret = rproc_handle_carveout(rproc, rsc);
> +			break;
> +		case RSC_DEVMEM:
> +			ret = rproc_handle_devmem(rproc, rsc);
> +			break;
> +		case RSC_TRACE:
> +			ret = rproc_handle_trace(rproc, rsc);
> +			break;
> +		case RSC_VRING:
> +			ret = rproc_handle_vring(rproc, rsc);
> +			break;
> +		case RSC_VIRTIO_DEV:
> +			/* this one is handled early upon registration */
> +			break;
> +		default:
> +			dev_warn(dev, "unsupported resource %d\n", rsc->type);
> +			break;
> +		}

Nitpick: A look up table would be easier to extend in the future.

Otherwise;

Acked-by: Grant Likely <grant.likely@...retlab.ca>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/