Hello Tiago,

nice to hear that you follow the component approach.

On Mon, Jun 06, 2016 at 04:54:46PM +0100, Tiago Brito wrote:

As said in previous posts I have a system call which is responsible for the SMC between the normal world and tz_vmm. I can successfully allocate memory in the normal world and access it in the secure world. Thus I can send images to the secure world (which is what I want). Then in the secure world I have a new component which uses the libpng port to process images.

This component runs in its own address space and, thereby, does not share memory mappings with tz_vmm after its creation.

TZ_VMM and the libpng component talk using the inter-component RPC. In order to access the image inside the libpng component I send Genode::addr_t in the RPC function call argument. This Genode::addr_t has the physicall address of the image which was loaded to memory from Linux.

I can verify that the addr_t variable has the correct value inside the libpng component, but when I try to access it this is the output:

[init -> tz_vmm] image addr: 816ac000 [init -> tz_vmm] RPC call: png_sig_cmp [init -> libpng_server] image addr: 816ac000 no RM attachment (faulter 27213c with IP 700101d4 attempts to read from address 816ac000) init -> libpng_server -> ep: unresolved pagefault at ip=700101d4 sp=e01fee30 fault address=816ac000 core -> pager_ep: cannot submit unknown signal context

Since this is a memory block which was allocated by Linux, and since I can manipulate it fine when inside tz_vmm, shouldn't I be able to manipulate this same memory region without problems?

As components use virtual memory (based on page tables) memory is addressed by virtual addresses. I assume that you use some facility in tz_vmm to calculate the virtual-memory mapping of 0x816ac000 and access the PNG in your original implementation. Now, you separated tz_vmm and your libpng_server into two components and, so, the memory mappings of tz_vmm are not directly accessible in libpng_server. Passing the physical address to libpng_server does not help as this component will not be allowed to create a virtual memory mapping to this portion of the RAM - it is exclusively accessible in tz_vmm.

I suggest you establish a shared-memory dataspace between libpng_server and tz_vmm big enough to transfer the PNG images. tz_vmm can then copy the PNG data from (Linux) guest memory into the shared dataspace where it is accessible by libpng_server. For an example, please have a look at Terminal::Session and the Genode Foundations book Section 3.6.3. and 3.6.5.

Regards