Shared Memory in tz_vmm demo

[Joseph Lee]

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 at ...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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20160405/4ef35e50/attachment.html>