• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Subscribers 353 subscribers
  • Views 7858 views
  • Users 0 members are here
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

Asynchronous External Abort and Trustzone

Vincent Siles

Hi !

I'm currently designing a secure monitor for an ARMv7 chip (i.MX6 from NXP, cortex A9 inside) and I'm thinking on a secure way to deal with asynchronous external aborts.

As I explained in a previous question, I sometime face the following situation:

- normal world is executing some code that will generate an asynchronous external abort

- a world switch (non-secure to secure) happens _before_ the external abort is actually generated

- the external abort will trigger during the secure kernel or a secure application

 

My goal is to be sure that, when I exit the secure monitor back to the secure world, no external abort can happen because of the normal world.

Most of the time, a simple 'check the ISR register' is enough because the abort will be triggered during the execution of the secure monitor, but I also face situation where the external abort is only triggered _after_ the secure monitor has finished switching.

 

Now, I'm wondering if there is a way to be 100% sure that no asynchronous EA are pending, while I'm in the secure monitor. My current solution is the following is to issue a "dsb; isb" sequence before checking the ISR, but I'd like to  be sure it is a valid solution to my problem.

 

Best regards,

Vincent

Parents
  • 0 in reply to Peter Rielly
    I don't talk about oob here, more like abort that can be triggered by trying to access a region protected by a TZASC (which is exactly how I trigger my test asynchronous abort). The software from NW may want to perform a denial of service on the secure world by trying to induce aborts using this way. I'm trying to see if there is a 100% sure option to prevent this.
    If that's not the case, I might have to ignore any EA, secure or not, because I can't be sure it is from the secure world or the normal world.
Reply
  • 0 in reply to Peter Rielly
    I don't talk about oob here, more like abort that can be triggered by trying to access a region protected by a TZASC (which is exactly how I trigger my test asynchronous abort). The software from NW may want to perform a denial of service on the secure world by trying to induce aborts using this way. I'm trying to see if there is a 100% sure option to prevent this.
    If that's not the case, I might have to ignore any EA, secure or not, because I can't be sure it is from the secure world or the normal world.
Children
  • 0 Arm Employee Badge in reply to Vincent Siles
    The Secure world can mask async exceptions (CPSR.A/PSTATE.A), and it has the option of terminating (or just not re-entering) the Normal world if it thinks it's being attacked.

    Again it comes back to what you are trying to achieve/use case. Say you think the Normal world software is either (a) broken or (b) malicious, what would you want the Secure world to do?

    If you take something like a payment of DRM use case, the Secure world is providing a service to the Normal world. In such a case, your response might to just stop providing the service.
  • +1 in reply to Martin Weidmann
    Yes, in the end, if it is not possible to be certain of the source of an async ext abort, their management will be "project based", so my monitor won't provide a full proof solution for this problem, only a way to let one world or the other (or none of them) deal with EA.

    Thanks you for the discussion and the infor !