synchronization between normal and secure world

[Norman Feske]

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.

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth