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

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 Peter Rielly over 7 years ago in reply to Vincent Siles

The problem is that external aborts are almost always imprecise so there is no way to link them back to an app or process.

Any out of bound accesses from secure apps should be caught by the secure world MMU. This gives a precise synchronous abort which you can link back to a context.
Cancel
Up 0 Down

Cancel

Reply

0 Peter Rielly over 7 years ago in reply to Vincent Siles

The problem is that external aborts are almost always imprecise so there is no way to link them back to an app or process.

Any out of bound accesses from secure apps should be caught by the secure world MMU. This gives a precise synchronous abort which you can link back to a context.
Cancel
Up 0 Down

Cancel

Children

0 Vincent Siles over 7 years ago 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.
Cancel
Up 0 Down

Cancel
0 Martin Weidmann over 7 years ago 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.
Cancel
Up 0 Down

Cancel
+1 Vincent Siles over 7 years ago 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 !
Cancel
Up 0 Down

Cancel