linux-kernel - Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)

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]

Date:	Fri, 10 Aug 2012 18:30:38 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Sjur Brændeland <sjurbren@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Omar Ramirez Luna <omar.ramirez@...com>,
	Fernando Guzman Lugo <fernando.lugo@...com>,
	Suman Anna <s-anna@...com>, Bhavin Shah <bshah@...com>
Subject: Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)

Hi Sjur,

On Thu, Aug 9, 2012 at 11:35 PM, Sjur Brændeland <sjurbren@...il.com> wrote:
> Any thoughts on how to go about to fix this?

The general direction I have in mind is to put the resource table in
its final location while we do the first pass of fw parsing.

This will solve all sort of open issues we have (or going to have soon):

1. dynamically-allocated address of the vrings can be communicated
2. vdev statuses can be communicated
3. virtio config space will finally become bi-directional as it should
4. dynamically probed rproc-to-rproc IPC could then take place

It's the real deal :)

The only problem with this approach is that the resource table isn't
reloaded throughout cycles of power up/down, and that is insecure.
We'll have to manually reload it somewhere after the rproc is powered
down (or before it is powered up again).

This change will break existing firmwares, but it looks required and inevitable.

Thanks,
Ohad.
--
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/