synchronization between normal and secure world

[Stefan Brenner]

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?

> 
> 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
> 

-- 
M.Sc. Stefan Brenner
Institute of Operating Systems and Computer Networks
Distributed Systems Group
TU Braunschweig

www: https://www.ibr.cs.tu-bs.de/users/brenner
mail: brenner at ...290...