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)
- normal world allocates a buffer in normal world memory
- 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