synchronization between normal and secure world

Stefan Brenner brenner at ...290...
Tue May 12 15:14:03 CEST 2015



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
> 

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




More information about the users mailing list