When we are learning about TrustZone® it does not take long to recognise that it is the security attributes for memory that define memory regions to be Secure, Non-Secure or Non-Secure Callable. This week’s video shows how the Cortex® M33 core with TrustZone® extension can test the security attributes for every read, write and execute from memory (without impacting performance). And how the security attributes are set with the Trusted Execution Environment configuration tool inside MCUXpresso IDE.

The interface between the M33 core and crossbar has been extended to with logic that tests the memory attributes on every memory access. Whenever the core makes a memory request, it passes through this logic on the way to the System bus. There are three modules:

• Security Attribution Unit (SAU);
• Implementation Defined (Security) Attribution Unit (IDAU) in combination with the Device Attribution Unit;
• An arbiter – the Security Attribution Logic.

The Security Attribution Unit – SAU – comes from ARM and behaves just like a memory protection unit (MPU). The SAU is programmed by software running in secure memory (by the secure project) in a function named BOARD_InitTrustZone() that can be found in c source module tzm_config.c. The NXP LPC55S69 microcontroller supports 8 different regions, and each is programmed with a start and finish (limit) address and the desired security attribute. The register interface is like this:

Code can read SAU_TYPE register and the field SREGION describes the number of supported regions. This field is 0b111 on LPC55S69, meaning 8 regions.

The important registers SAU_RBAR and SAU_RLAR and duplicated 8 times, one for each region descriptor. We select the registers to be programmed with the index register SAU_RNR. And so if we want to progam region 5, we write the REGION field in SAU_RNR to 0b101 and then write to SAU_RBAR and SAU_RLAR. These register support setting the base address and the top (limit) address for the memory region. Finally, note the NSC bit SAU_RLAR. When set, this designated a region to be Non-Secure Callable. When clear (0b0) it sets the memory attribute to be Non-Secure.

Observe that in this scheme we are able to program regions to be Non-Secure or Non-Secure Callable. Any memory address that does not fall into a programmed region will default to being Secure. Here is an example from hello-world_s:

Back in the Core architecture, there is another security attribution unit – the Implementation Defined Attribution Unit. ARM recognise that 8 regions may not give sufficient granaularity and number of regions, and so they allow the microcontroller suppler – NXP in this case – to extend the security regions with their own strategy.

It’s been mentioned before, so a simple reminder – NXP have defined that address bit 28 defines if a memory area is secure of non-secure. There is an exception – at the bottom of the memory map where Program and Data memory is located – all of memory from 0x0000_0000 to 0x2FFF_FFFF defaults to Non-Secure. We can then use the SAU to define the attributes for these memory regions.

Now that there are 2 logic blocks – IDAU and SAU – to configure the security attributes, we need an arbiter (or logic) to combine them. This is the function of the Security Attribution Logic.

Within MCUXpresso IDE is a Configuration tool – the Trusted Execution Environment – that allows us to quickly configure the Security Attribution Unit and generate code for our project. The tool enables us to set memory regions, and the desired security attribute, and display these graphically. A convenient checkbox “Merged SAU+IDAU” is demonstrated in this week’s video to show the output from the Security Attribution Logic and we see the combined effect of SAU and IDAU.

After some theory, the main focus of this week’s video is to look at the TEE configuration tool. It’s embedded here:

Feel free to head over to the embeddedpro® channel on YouTube to watch this and earlier videos. As always I am happy to hear your comments and feedback, and come back next week when I’ll blog about a real world TrustZone® use-case: Heartbleed vs TrustZone… who wins?