On 10.05.2015 19:32, Norman Feske wrote:
Hi Stefan,
Thanks for your answer. While in short term we are actually working with imx53 which is a single core your assumption holds of course. Still I am worried about the impact of IQs and FIQs that might disturb us while consuming or writing data in both (secure and normal) worlds. In long term we would like to even move on to a multi core plattform.
So as far as I see it, I think in our case it is unfortunately not that easy. We can not just assume implicit synchronisation through TrustZone being either in secure or normal world at a time, but interrupts (and later the multi core arch) will make our life harder. Please correct me if I am wrong here (would be happy to be wrong, to be honest).
I don't think that interrupts are a concern here. As long as the tz_vmm is active with processing an SMC, normal-world interrupts are masked. The normal world will receive its next interrupt not before tz_vmm has finished its work.
Well, it seems like you are assuming a different system design than we actually have. I don't say our design is the "holy grail", but let me describe how things currently work:
(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.
So, I think unfortunately in this design interrupts are definitely a concern, right?
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.
Maybe this is the wrong way approaching our goal. What we need is a way to communicate between secure (Genode) and normal (Linux) world such that we can send and receive any possible byte buffer.
On a multi-processor system, each CPU can be in the normal or secure world independently. Hence, it would be sensible to use a dedicated tz_vmm handler with a separate shared memory buffer for each CPU. Alternatively, the normal-world OS may synchronize SMC calls similar to how it usually synchronizes the access to a peripheral device. Neither of both designs would require mutex-based synchronization between the secure and normal world.
Could I clear up your doubts a bit? ;-)
Best regards Norman