Hi Stefan,

Thanks a lot for your response.

I have another questions. I have tried to measure the time for the context switch between the worlds. I make an SMC call in the normal world (Linux) and modified the VMM to return to the normal world without doing any operation. I take time t1 before calling the SMC instruction and time t2 after the secure world switches back to the normal world. Then the difference (t2 - t1) is the time for the context switch. i am getting around 0.05 milliseconds. Is that the right way to measure the time for the context switch? FYI, i use getrusage( ) function in Linux to measure t1 and t2.

How do we measure time for a process in Genode. Is there a method to get time in Genode? Thanks again for you help and time.

Kind regards,

Joseph

On Tue, Apr 5, 2016 at 10:01 AM, Stefan Kalkowski <stefan.kalkowski@...1...> wrote:

Hi Joseph,

On 04/04/2016 07:17 PM, Joseph Lee wrote:
> Hi,
>
> I used "*dma_alloc_coherent( )"* as described in this thread (
> https://sourceforge.net/p/genode/mailman/message/34685275/) to allocate
> shared memory between the trustzone worlds in the tz_vmm example on i.mx53
> qsb. It works well. But my questions is how do we prevent the normal world
> from modifying this shared buffer while it is being used by the secure
> world. Thanks in advance for answers.

this might be an issue in multi-processor environments only, where more
than one core is used by the non-secure world. In the uni-processor case
(the only one we experimented with TrustZone yet: CortexA8) either the
secure world is running, or the normal world. As long as you do not
schedule the non-secure Linux it won't run, and this is in the hands of
the VMM, which handles traps and calls from the VM, and also makes it
runnable again.

But even in the multi-processor case I would question whether this is a
problem. In the normal case the guest OS should not touch the shared
buffer after it send a request to the secure world. The VMM then copies
the message out of the shared buffer and parses it. If the guest OS
maliciously changes the shared buffer during the copy process that would
result in a broken message. But the guest OS could place such a
malicious message already in the first place. The parsing routine of the
VMM must be robust against any kind of content it gets anyway, similar
to all kind of input-data handlers from unsecure sources (e.g.: web
formular interpreter ...).

regards
Stefan

>
>
>
> Kind regards,
> Joseph
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> genode-main mailing list
> genode-main@...49....sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>

--
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/

------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
genode-main@...12...ceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main