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: bren...@ibr.cs.tu-bs.de ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main