You might purchase a Cortex® M33 microcontroller with TrustZone® where the supplier has installed a secure ROM. Or you might be an IOT developer using LPC55S69 in your own application where you have partitioned the code into secure and non-secure partitions. At some point with Cortex® M33 core with the TrustZone® security extension you’ll want to transition from non-secure into the secure world. Or (put more elegantly), you’ll want to call one of the secure functions supported when the Cortex® M33 core is in the Secure state.

That’s the topic for this week’s video.

How will you know what secure functions are available? And what parameters are necessary to call these functions? You’ll be provided with a header file veneer_table.h and a secure object library named project_name_CMSE_lib.o. Together these 2 modules describe everything that you need to know to call a secure function and transition from the Non-Secure to the Secure state.

You can spend a morning trying to reverse engineer these two modules. But you’ll not learn anything about the functions in the secure world, only how to call them. The library project_name_CSME_lib.o does not contain the functions, but only the gateway instruction followed by the function call (it is an object library, not an assembler library). And since all of the supported functions are called through the function table (shown in blue, and named the Veneer Table) you won’t even learn the size of each of the functions.

After a little theory, the video this week investigates the Veneer Table in MCUXpresso IDE. I’ll show you the Veneer Table in a debug session, in the Disassembly view, and quickly we see the sg secure gateway instruction prefixing each function call into the secure world.

It is this sg instruction that polices the transition from the Cortex® M33 ‘Non-secure’ state into the Secure state. To make this transition, there are two requirements.

• Firstly, the sg instruction must ben in an area of memory with the Non-Secure Callable attribute set (we’ll see this next week).
• And secondly, the first instruction must be that ‘sg’ instruction.

The enterprising hacker could write some non-secure code that attempts to call functions in the secure world. It could simply jump to every secure address. If that target address contains some data 0x7FE97FE9 – this is the opcode for sg – then the Cortex® M33 core would transition from non-secure to secure state. But this only fulfills the second requirement. That data will be in memory with the Secure attribute set, not the Non-Secure Callable attribute. So the test will fail and the chip will call a Secure Fault exception.

Feel free to head over to the embeddedpro® channel on YouTube, or you can watch the video embedded here. As always I am happy to hear your comments and feedback, and come back next week when I’ll blog about how the security attributes for memory in a TrustZone® project are configured with the Trusted Execution Environment tool.