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. I believe from looking at the sigma0 code that any memory, I/O or RAM, can only be allocated to one L4 process at a time.
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?
Thanks,
Hi,
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. I believe from looking at the sigma0 code that any memory, I/O or RAM, can only be allocated to one L4 process at a time.
Yes, any page or port can only be given to one client.
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?
Adam
Hi,
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.
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.
Thanks, -- Wesley Miaw wesley@wesman.net
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
Hi,
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?
I thought if I had a process release its memory then another process could be granted it. And so I could map and then unmap for reach request. But it sounds like I should look into the io server a bit more, or re-read through how moe can configure things.
Thanks,
Hi,
On Mon Jan 30, 2012 at 19:35:45 -0000, Wesley Miaw wrote:
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?
I thought if I had a process release its memory then another process could be granted it. And so I could map and then unmap for reach request. But it sounds like I should look into the io server a bit more, or re-read through how moe can configure things.
Generally multiple tasks can have access to the same memory, be it RAM or devince memory does not matter. Doing map/unmap operations for each request also sounds expensive to do. I think io is the one to look into, moe has no business with non-ram memory.
Adam
Hi,
Everything seems to be working now that I've defined the RAM as a region in the Io server's configuration file. After requesting access via l4io_request_iomem_region() in both my tasks they can read/write the memory. Thanks.
Generally multiple tasks can have access to the same memory, be it RAM or device memory does not matter. Doing map/unmap operations for each request also sounds expensive to do. I think io is the one to look into, moe has no business with non-ram memory.
This confuses me. I thought part of sigma's job was to hand out memory as needed, and only to do so to one task. I remember seeing something in the sigma library code that checked who the owner of the memory was before returning it. Otherwise what prevents one task from clobbering another task? Or does that only apply to memory that is indirectly requested/allocated like via new/malloc?
Thanks,
Hi,
On Tue Jan 31, 2012 at 21:55:30 -0000, Wesley Miaw wrote:
Everything seems to be working now that I've defined the RAM as a region in the Io server's configuration file. After requesting access via l4io_request_iomem_region() in both my tasks they can read/write the memory. Thanks.
Ok.
Generally multiple tasks can have access to the same memory, be it RAM or device memory does not matter. Doing map/unmap operations for each request also sounds expensive to do. I think io is the one to look into, moe has no business with non-ram memory.
This confuses me. I thought part of sigma's job was to hand out memory as needed, and only to do so to one task. I remember seeing something in the sigma library code that checked who the owner of the memory was before returning it. Otherwise what prevents one task from clobbering another task? Or does that only apply to memory that is indirectly requested/allocated like via new/malloc?
sigma0's policy on handing out memory is a simple FCFS, so sharing is typically implemented using a third component (e.g. moe). This third component will allow for memory sharing given some configuration and then it is up to the tasks to get that sharing right. In sigma0 there's no way to remove a connection between a client and a page once it is made, i.e. this is up to other components.
Adam
l4-hackers@os.inf.tu-dresden.de