synchronization between normal and secure world

[Stefan Kalkowski]

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/