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.kalkow...@genode-labs.com> 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 >
------------------------------------------------------------------------------
_______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
