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@lists.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main