• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 6473 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[Trustzone] interrupt level fast world switch(NWD->SWD) solution?

ray mao
Note: This was originally posted on 11th October 2012 at http://forums.arm.com

Dear ARM Engineer,

I have a question about interrupt level fast word switch for trustzone enabled ecosystem.
For scenario - 1 core is running in one World, interrupt of the other World happen. How to switch the core to the other world quickly.

Solution-1
In the whitepaper prd29-genc-009492c_trustzone_security_whitepaper.pdf
one solution is already mentioned. - monitor route slolution.
but this solution need carefully deal with monitor, NWD OS, SWD OS interrupt related code.

Solution-2
I was checking another solution which one World OS actively do swtich directly while the other world interrupt happen.
From ARM GIC Spec, spurious interrupt ID 1022 & 1023 seems to be possible as the flag.
(Suppose NWD only use IRQ, SWD only use FIQ)
After test,
1022 can help SWD->NWD  for case cpu core in SWD and IRQ happened.
1023 can not help NWD->SWD for case cpu core in NWD and FIQ happened. (As 1023 will also happen in other case)

So is there any extra flag/way can help Solution-2 do NWD->SWD.
Or say Besides Monitro solution, is there any other way can help interrupt level fast word switch NWD->SWD while  FIQ happen.

Thanks!
  • Note: This was originally posted on 12th October 2012 at http://forums.arm.com

    Thanks for reply, guys

    We all agree monitor solution is better(best) solution to this case.
    monitor solution has better performance but inflexible.

    I mean, for one world OS, giveup CPU stradegy can be changeable while the other world interrupt* happen.
    e.g.
    1.every interrupt* happen do world switch
    2.every N(2,3) interrupt* happen do world switch
    3.only NOT in critical area code(hope to be finished before switch), interrupt* happen do world switch

  • Arm Employee Badge
    Note: This was originally posted on 12th October 2012 at http://forums.arm.com

    Why is it inflexible? It's entirely configured by software.

    If you want it to behave like any other interrupt handler (i.e. allow nesting of secure and non-secure interrupts in either direction) just allow the normal world to mask FIQ in the NSACR in CP15. The only overhead over "single world model" is the latency of the monitor transitions, but other than that it should behave like any OS behaves with interrupts masked (or not).

    The behaviour is entirely down to how your security use cases need to function, and what attacks you want to prevent. TrustZone provides a bag of tools, and is very flexible - restrictions need only be applied if your use case needs them ...
  • Arm Employee Badge
    Note: This was originally posted on 11th October 2012 at http://forums.arm.com

    Whatever happens you need to go through the monitor - it's the gate keeper between the two worlds, and ensures no unintended data leakage from secure to non-secure.

    For A-profile cores the trustzone monitor overhead tends to be in the noise - the code is usually only a couple of hundred CPU cycles - most A-profile cores lose more time than that in the interrupt handler due to cache and tlb misses. So before you try to micro-optimize and throw your security in the bin, please check that you actually need the interrupt to go faster. In reality you probably don't.

    Iso
  • Arm Employee Badge
    Note: This was originally posted on 11th October 2012 at http://forums.arm.com

    The basic problem with (2) is that it relies on both OSs (NWD and SWD) behaving.  Probably not an issue for the Secure world OS.  But for the Normal world OS, if it were compromised (and because of this risk you have TZ), the malicious code could easily prevent you ever switching back to the Secure world.

    The advantage to (1) is that the FIQ is beyond the control of Normal world OS, so if compromised, you can set enter the Secure world.