Sharing I/O Memory

[Adam Lackorzynski]

Hi,

On Mon Jan 30, 2012 at 09:12:47 -0800, Wesley Miaw wrote:
> On Jan 30, 2012, at 1:13 AM, Adam Lackorzynski wrote:
> 
> > On Fri Jan 27, 2012 at 18:15:46 -0800, Wesley Miaw wrote:
> >> I have an L4 process requesting access to a large chunk (512MB) of
> >> physical RAM using l4sigma0_map_iomem(). I am not using l4sigma0_map_mem()
> >> because Fiasco is running in a different partition of physical RAM.
> >> 
> >> I would like to then grant full read/write access to the same memory to a
> >> second L4 process, but I'm not sure how to do that.
> >> 
> >> It also doesn't look like clans have anything to do with this, other than
> >> the possibility of creating some shared memory for an IPC. But that's not
> >> really what I want to do, I want both L4 processes to directly access the
> >> memory. Is there some way to accomplish this?
> > 
> > Common practice is to have a roottask which handles allocation of memory
> > in the desired ways. With 'directly access' you mean that no roottask (or
> > similar) can revoke access to the memory?
> 
> Hm. This is related to the TrustZone work I am doing. I have a
> userland boot loader, launched by moe, mapping 512MB of RAM using
> l4sigma0_map_iomem() and copying the Linux kernel into there. But I
> want various secure services to handle requests from Linux in their
> respective L4 userland memory spaces. However that means they will
> need to access memory in that 512MB of RAM to read and write
> information to handle the request.

Yep, at least one needs to do that.
 
> I couldn't find any way to revoke access once granted via sigma0. Or
> for a L4 userland process to "put back" the memory it has previous
> requested access to.

Processes can unmap their memory themselves, or those inbetween. Just
not sigma0 because that's not its task. io is handling everything
non-ram for multiple clients etc.
I'd think of the normal side as a device which has some (big) MMIO and
handle it that way on the secure side. Why would you like to get rid of
the memory again?



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/