On 06.05.2015 10:26, Norman Feske wrote: > Hi Stefan, > >> It would be more suitable for my app to not do the critical action in >> normal world, but ask the secure world to do it. Then it would be >> synchronized as well, but only one world switch back and forth necessary. >> >> I think I have to bite the apple and implement what you mention, a mutex >> in a shared memory section. Do you have any further input for me >> according to this? Especially about the "mapped uncached" property? > > I hope you don't mind me chiming in. I doubt that mutex-based > synchronization of a shared buffer between both worlds is the best way > forward. Instead, I would investigate a protocol similar to Genode's > synchronous bulk transfer approach as described in Section 3.6.5 of the > upcoming manual [1]. > > In short, while the normal world is active, it can freely access the > memory without the need for synchronization. To hand over the data to > the secure world, the normal world performs a secure method call (smc) > to the secure world. While the secure world is active, the normal world > cannot (by definition [2]) be active. So the secure world can safely > consume the data (e.g., by copying out the data from the shared buffer > to a private buffer). Once the secure world is finished, the smc call > returns, which implicitly hands back the "ownership" of the shared > buffer to the normal world. Would that approach possibly work for you?
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). The only thing I see here is that interrupts - even though they will actually happen - dont affect our shared memory. Probably depends on what the ISR is doing, if it will just finish its job and return back to the world running before the interrupt happened, then it might be fine. No? > > Cheers > Norman > > [1] > http://genode.org/files/53bcb8e33fe6602fed25edc3c7b922c5/manual-2015-04-27.pdf > [2] On the multi-processor system, this may not be true. Here, the > normal world would need to perform the synchronization of smc calls. > But this synchronization does not involve the secure world. > -- 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
