TrustZone and "its" NS bit

Hi David,

Within a TrustZone SoC, memories are divided into secure memory regions and non-secure memory regions. When processor is in secure mode (running secure applications) it can access secure memory regions (as well as non-secure memory region if needed). When processor is in non-secure mode (running non-secure applications), then it can only access to non-secure memory region.

In order to handle this, the AMBA bus infrastructure must be able to determine if the transfers are secure and non-secure. In AXI it is indicated by one of the APROT bits. ARM also has several system components like TZIC (TrustZone Interrupt Controller - for separating interrupt into secure type and non-secure type), TZPC (TrustZone Protection Controller - for controlling peripheral access right).

There is tagging for data - in the cache. In cache controllers like L220 from ARM, there is a bit for each data line to indicate if the data is secure. In this way non-secure application can be blocked from obtaining cached secure data.

In summary, a TrustZone system needs:

- A TrustZone enabled processor (e.g. ARM1176)

- TrustZone enabled AMBA (bus system, e.g. AXI)

- TrustZone Interrupt support system (non-secure application can cause the processor to enter secure state only by secure interrupt), e.g. TZIC.

- TrustZone application code

- TrustZone enabled debug system (Normally application developers are not allowed to trace secure applications, so the debug interface need to able to tell secure and non-secure activities) E.g. CoreSight debug architecture from ARM.

Note: Compiler does not need to know anything about TrustZone. Secure applications and non-secure applications are developed and compiled separately, and located in separated secure and non-secure memory.

For more information visit:

Hope this helps.

Joseph

This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an intended recipient of this e-mail message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this e-mail message may violate various laws in your state, country or jurisdiction. If you have received this e-mail message in error, please contact the originator of this e-mail message via e-mail and delete all copies of this message from your computer or network, thank you.

Thank you Joseph for your answers !

but I still have some questions :

- do two differents secure applications share the same secure zone ? or they have distinct zones ?

- and when is the NS bit is tagged ? (i.e How secure application tag is made ?) Is it possible after it to modify this NS-Bit ? (i.e if a "bad person" wanted to access to the secure environment by an other application ?)

Thanks, have a nice day.

Joseph a =E9crit :

You can have multiple secure regions in your memory map. So you can separate the application into different secure regions. However, they can access each other code/data unless the MMU block them.

This is explained in ARM1176 TRM page 2-4

NS bit is in Secure Configuration Register (SCR). This register can only be accessed in Secure priviledged modes. You should also read page 2-3 (section 2.2.1) for TrustZone model, and page 2-10 for system boot sequence. This will give you a better idea how it work.

regards, Joseph

Thank you again for your answers ! the document will help me :)

Have you the same links for ARM926 and ARM1136 processors ? because i didn't find them on the website ! :(

Have a nice day. David.

You're welcome David. ARM926 and ARM1136 don't have TrustZone support. The Technical Reference Manual for these two processors are in:

You can find documentation of most ARM product on ARM web site.

Joseph

This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an intended recipient of this e-mail message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this e-mail message may violate various laws in your state, country or jurisdiction. If you have received this e-mail message in error, please contact the originator of this e-mail message via e-mail and delete all copies of this message from your computer or network, thank you.

thank you for the links.

a last little thing if you know where can I find this document "ARM Architecture Reference Manual, Security Extensions supplement". I don't find it in the documentations section ! is it public ? because in the others documents they refer to it. or is it a book ?

Thank you again.

Have nice day :)

Hi David,

This document is not on ARM web site. I guess you need to contact ARM support directly. (I am not sure if it is a public document either).

Joseph

This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an intended recipient of this e-mail message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this e-mail message may violate various laws in your state, country or jurisdiction. If you have received this e-mail message in error, please contact the originator of this e-mail message via e-mail and delete all copies of this message from your computer or network, thank you.

In this particular case it doesn't matter too much, but in general on usenet you should realize that readers may very well not have convenient access to previous articles in a thread. That means that your reply articles should include adequate context, so that they stand by themselves. Google is NOT usenet, it is only a very poor interface to the real usenet system. To include proper context when using google, see my sig. below. Please be sure to read the referenced URLs.