Hi, On 05/12/2015 04:02 PM, Stefan Brenner wrote: > > > On 12.05.2015 15:47, Norman Feske wrote: >> Hi Stefan, >> >>> (secure world=Genode, normal world=Linux) >>> 1) normal world allocates a buffer in normal world memory >>> 2) normal world issues an SMC and transmits the buffer's address to >>> secure world where addresses are translated >>> 3) secure world stores the address >>> 4a) normal world writes something to the shared buffer and modifies some >>> meta data structures. Basically, it writes to the metadata "Hey, secure >>> world, there is something for you". >>> 4b) secure world busy-waits (ugly) until it reads something new from the >>> normal world, and starts processing it. >> >> are you using the tz_vmm example at _os/src/server/tz_vmm/_ as blue print? >> >> The points 1 to 4a are consistent with my suggestion. But instead of >> letting the tz_vmm poll for new information (4b), I propose to let the >> normal world issue an SMC call each time it has written something >> meaningful to the buffer. So the tz_vmm could simply block for SMC calls >> (wait_for_signal) and each time a signal comes in, it would process a >> new request. Not before finishing the work, it would pass control back >> to the normal world (by issuing _vm->run()). With "finishing the work" I >> mean that the tz_vmm applies changes to its internal state. It should >> not wait for a blocking operation between the reception of a signal and >> calling '_vm->run()' because this would stall the normal world. > > Ok, that sounds promising to me. Thanks for the hint. However, I see one > problem for us here. If the secure world should handle long running > tasks (large computation), using your proposed mechanism the normal > world would be paused while computing in secure world, right? > > But what we need is the ability for the normal world to send further > requests to secure world and to respond to network packages during the > secure world's computation. So we need a way for the secure world to > notify back to normal world when the computation has finished and the > response/result has been put to the message queue (we have another queue > for the answers). > > Afaik, in tz_vmm example (btw, yes, we have been starting from this > example originally) the smc in the other direction (from secure to > normal) unfortunately is not intended at the moment, right? >
In our example there is no such use-case. Anyway, to signal from secure to normal world you can inject an interrupt. Of course a 'smc' instruction by definition (secure monitor call) would not work in this case. In case of the Freescale interrupt controller have a look at the Software Interrupt Trigger Registers (TZIC_SWINT) to trigger a software interrupt that you previously assigned to the normal world. I did not had time to test it out on my own, but this way it should work. Regards Stefan >> >> Essentially, tz_vmm should be understood as a state machine. State >> changes are triggered by signals and applied in the '_handle_vm' >> function. An SMC request is such a signal. >> >>> Basically, we implemented the buffer as a message queue abstraction, so >>> it will offer read() and write() messages, and it allows to send >>> messages of (almost) unlimited size via the queue. >> >> That sounds fine. >> >> Cheers >> Norman >> > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ ยท http://genode.org/ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ genode-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
