synchronization between normal and secure world
Stefan Brenner
brenner at ...290...
Fri May 8 15:10:54 CEST 2015
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: brenner at ...290...
More information about the users
mailing list