The webinar recording can be accessed at the link below:
Webinar Description
Securing embedded systems has become a critical task for developers. It is nearly impossible to turn on the news and not hear about yet another major security breach. In this webinar, attendees will become familiar with the design methodologies necessary to secure their embedded systems using the new Arm® TrustZone® for Cortex®-M processors. We will examine important concepts, such as Secure and Non-secure domains, setting up a TrustZone RTOS and debugging a secure application.
This webinar will provide a hands-on demonstration, powered by the Arm Cortex-M23 processor, which is the first Cortex-M processor to support TrustZone. We will use Arm Keil MDK to demonstrate how to get TrustZone up and running on both hardware, and also in simulation, using a virtual processor.
Topics covered in this webinar Include:
– Introduction to TrustZone
– Defining the Secure and Non-secure world
– Example use cases to secure an application with TrustZone
– Implementing FreeRTOS™ in the TrustZone environment
– How to debug a TrustZone-based application
– Best practices for securing an embedded system
– Recommendations for next steps
Access the webinar recording below:
Below are the questions that were asked during the webinar along with the answers to those questions. Feel free to post further questions as comments to this post.
| Questions | Answers |
| Are there any disadvantages (in terms of performance) if you configure all peripherals and memory regions as secure? | When switching from non-secure to the secure region, there is up to a 3 clock cycle overhead to call a secure function. Once in the secure region, there is no performance hit to using a secure peripheral. |
| As material level is participating in making of secure zone I would want to know if there is separate device(for example memory chip) which could be coupled to secure area to increase its capacity in memory sense or in processing sense? | memory external to the chip (external memory) can be assigned secure region to extend your “secure memory” space. All 4GB address addressable by the Cortex-M23 must be assigned to either secure or non-secure. |
| Do we have any seperate instructions to access the secure region of memory? | Yes. When calling a function in the secure region, the SG instruction is inserted to tell the CPU that a secure gateway connection is being used. There is also a new “return” instruction that is used when transitioning from the secure world back into the non-secure one. |
| Does this protect against software attacks like stack/buffer overflow exploits and Return Oriented Programming (ROP) as well? | A developer in these instances should still employ overflow checks and the MPU but since you could have a secure data, it can make it harder for a hacker to use these exploits |
| For examle, regarding smartphone device, key input pad is handled as a secure device? | It could be put into secure code if it was deemed to be required. You might put things such as an RTOS scheduler, secure boot code, TLS and encryption libraries into secure flash. |
| From what I understand the main developers of TrustZone will be those developing OSes, and only at a later stage application developers will be facing the need / if at all, to work directly with TrustZone? Or am I misunderstaning this? | You are misunderstanding. When you start developing your application, you need to set your security strategy which will include deciding what functionality goes in the secure region. From the first power-up you’ll need to configure you non-secure world and also setup secure boot and possibly have important functions placed in the secure region. |
| How about I use some part of external memory as secure world and while in operation I expereince a power cut then the (external memory)secure world will be erased since it is volatile? (how to handle this, please suggest) | At that point, I would expect the MCU to also restart and be in the secure flash boot region which would then reinitialize the application. It would be a very rare case for the external memory to lose power while the MCU did not. Othewise you could use a supercap to cover any power loss on the MCU and external memory. |
| how is the non-secured memory region makes a call to secured memory region and still remains secured? are we referring to similar practise as encapsulation and abstraction? | A secure gateway instruction is used to switch from the non-secure to the secured region. Only specific addresses in the secured space can be called. Any other address will result in an exception. So there is literally a hardware transition that occurs in the hardware that keeps the two regions isolated from each other. |
| How the secure area and unsecure area comunicate with each other?( if they have to) | The secure region has access to everything in microcontroller including the non-secure regions. The non-secure region can only make function calls into the secure region. The functions that can be called from the non-secure world are specified through an interface so that a secure gateway or veneer region is created so that only that specific memory location can be executed in secure space. Attempting to dereference any areas not specified cause an exception to occur. |
| I mean, technical means (like TrustZone, TrustedPlatformModules, uVisor, …) are still “only tools” that need people that deeply understand the security implications of applications (side-channels, storage, …). How to make sure that all people involved in a product development (management, pre-development, designers, developers, testers, …) become aware and ready for the new challenges that are awaiting us? | Yes so TrustZone is just one more piece in the puzzle or one more layer in the onion. It really comes down to educating management on how important security is and then putting in place training, mentoring and security reviews to properly evaluate the application and product that is being developed and creating a good strategy for it. |
| If for instance I am a user of mbed-os, will I be directly able to take advantage of the TrustZone, or do I need to wait for mbed-os to support it? | You need to wait for mbedOS that supports the TrustZOne enabled Cortex-M. STay-tuned. |
| In some places of the presentation you used RED color for Secure, and GREEN for Non-Secure, in others you did viceversa 😉 | Thanks. Places where it is swapped might have been where images were pulled from application notes. |
| Is it possible to configure any of the peripherals to be secure or non-secure? | Yes |
| Is secure storage always included secure side on M-devices if the device has TrustZone enabled? If not, where is secure storage located otherwise?
The reason for asking is because on the A-Architecture TrustZone typically relies on flash in non-secure world to store the actual data. |
You can use your secure flash space to store secure data that is non accessible from the non-secure world. Some standard Cortex-M parts also may have special regions designed for secure storage. For example, if you look at some of the new ST Micro parts, they include a secure memory storage for keys and other secure data. |
| Is the bluetooth module a ESP8266 chip? ESP8266 is wifi only.. | I am not sure. I will need to review the schematic and get back to you. |
| Is the Nuvoton M2351 readily available somewhere (can’t really find much information about it on their page)? Are there other Armv8-M devices available to the general public? | The Nuvoton M2351 is the first Cortex-M to support TrustZone. It is currently in pre-production and will be available in the next several months. If you are interested in getting one, you can email the Nuvoton support or also email jacob after the webinar and he will direct you to someone who can get you more information. |
| Is there a way to prevent debugger from debugging secure world? | Yes. If you compile your secure code into a library and distribute that library or just flash the library onto a microcontroller in the secure space, anyone working in the non-secure world will not be able to see the code in the secure region or the secure data. So if you are debugging non-secure code, you won’t be able to see the secure world. |
| Is there an overhead in terms of power and performance? Also when transitioning back to secure are registers restored/ Finaaly is this webinar available for later reference? | The performance hit is 3 clock cyles which will result in minimal power overhead. It depends though how often your application is switching between the zones. When switching from secure to non-secure, the non-banked registered are cleared in order to prevent exposing any information to the non-secure world. Yes the webinar will be available. Watch for an email within 24 hours. |
| Is there any connection between uVisor and TrustZone? | Not necessarily. uVisor exists for Cortex-M processors without TrustZone as well. With TrustZone enabled Cortex-M, uVisor will run more efficiently because secure-non-secure is controlled by HW. |
| Is there any performance overhead running secure code vs running non-secure code? | Each transition from non-secure to secure world requires up to 3 clock cycles overhead to switch in hardware between these regions. |
| Let’s take the case I distribute a library intented to execute in secure area. Can anyone use a debugger to step into the library, as thus trace the execution in the secure area ? | “Secure debug” that only allows debug visibility to non-secure region, and only allow visibility to secure region for authorized debug session, is a feature that can be different for each MCU. For the Nuvoton M2351, secure dbug is supported. Please reach out to Nuvoton for more details. |
| The interface code in the secure area is defined az macros. what code is generated for that? Is it different from “normal” function? | The macros for TZ are abstracting some complexity to create and check function pointers. There are attributes within the CMSE library that when used with a function tell the compiler that the function is accessible outside of the secure region. For these functions, secure gateway (SG) instructions are generated behind the scenes. |
| This prompted me to think that their are no exceptional or hardware design level changes to make this particular arm processor, am I correct?(if not please throw light) | There are changes in the silicon to separate the secure and non-secure regions of memory. From an external component stand-point there are no differences. In the microcontroller there are changes to isolate the secure and non-secure region through hardware. |
| What about linker script? Is this handled automatically in some way or maybe the user needs to define secure memory regions in scatter file manualy? | In Keil you can configure this through the project options or manually create a scatter file |
| What about support for this in toolchains such as GCC, LLVM? Is it supported? If not any plans to add support for it? If yes, roughly when? | GCC already supports Cortex-M23, which is based on Armv8-M architecture. Please email us for a link.,https://developer.arm.com/open-source/gnu-toolchain/gnu-rm |
| What are the main differences in comparision to use a MPU? | There is hardware isolation between the secure and non-secure region and only specific function executable regions are made available in the secure region. The secure and non-secure world can still both have an MPU. |
| What do I need to do to control ( to protect is more suitable) this particular communication with secure and unsecure region?( Just to say a dedicated program to handle it) | You would identify functions and data that need to be secure and have restricted access and those would then be placed into the secure world. |
| What I can do to increse the Secure area?( is there any way, if yes please suggest) | You can use the SAU to set the secure regions and also adjust the scatter plot (linker file) to set the secure memory areas that are needed for an application. |
| When combining RTOS in normal state with library functions called in secure state, is the system still fully preemptible? Or should secure function first run to completion? | Everything is still preemptible |
| are the __attribute__s seen Keil-specific? Is there support in gcc? | Yea that is the keil specific syntax. In gcc, the csme attribute is the same you would just use the gcc version. |
| Can ARM SecureZone be used with different 3rd party compilers? | Yes any compiler that can handle the armv8-m. |
| how do you protect the root of trust code itself? against being modified | The application boots directly into the secure memory. Secure zone also has an MPU and cannot be accessed from outside the secure world. Someone with access to secure code could update that code from within the secure zone. |
| How does firmware upgrade with deep embedded processors work? | You can use a bootloader to update the firmware. |
| If the partition file is absent in a project, will the m23 and m33 act the same as a regular Cortex-M processor? Is it required if you do not plan on using TrustZone for a project? | An MCU that includes TrustZone will always boot in secure mode. It is then possible to set all memory map with non-secure attribute. You still need the first transition from secure boot into non-secure. |
| Is it started? cant hear anything…just screen “Questions” | I’m sorry to inform you that you just missed it! The recording will be sent out though in the next 24 hours. |
| Is the transition to/from done via software or hardware on nuvoton? | the transition is done in hardware on any M23/M33 part. |
| Looked like lots of printfs even for turning on/off an LED, were they going to dev/null? | Yea it was just part of the example to show that you could have a non-secure UART that is controlled in both the secure and non-secure zones. |
| What is a Keil FVP? | fixed virtual processor |
| You mentioned if you try to execute secure code from non-secure execution, you get a fault. How does the secure code handle this. Is it simply an ISR, and then decision made, or is it possible to RESET the device and kill the threat? | Yes so trying to execute a function or dereference memory outside defined secure gateway addresses causes a fault. These show up as an interrupt and then a developer can take whatever course of action they deem fit to avert the threat. |
| where is the initial code stored? if you want it to run only if it passes some kind of auth. | Yes they will be posted on beningo.com late this week or early next. |
| How can I look at memory in the secure zone with SWD? | |
| When compared with software how many cycles does it typically take to switch to/from secure/non-secure state? I heard hardware takes 3 cycles. | oh. It’s a simulation. no hardware, just simulated processor. |
| I know what it stands for. What does that mean? | |
| The code starts in the secure zone as we saw in the previous demonstration. | it starts in secure zone, but it has to be stored in some kind of NVM. how do I block an attacker from replacing ny root of trust code with malicious code? |
| You can isolate and protect those memroy regions with a secure key that must be entered to program the flash. | thanks. will this mechanism be effective against pysical atracks on the NVM? |
| Did you use freeRTOS for this demo? | Yes. Other RTOSes could also have been used such as embedOS or RTX. |
| What’s the overhead for calling into the secure state from the non-secure state? | at most 3 clock cycles |
| more than just the core? | yes |
| Does trustzone only apply to Flash memory? Is it possible to protect RAM functions? | it applies to flash, ram, interrupts and peripherals |
| Do you have to clear the pipeline with an ISB instruction after going from secure to insecure? | No. You attach an attribute from the csme library and it will automatically clear the nonbanked registers when going from secure to non-secure |
| Thanks. Do nonbanked registers include the 3-stage pipeline for the Cortex M33? | Cortex-M33 contains the same 16 32-bit non-banked registers, except for the stack pointers (R13) that is banked for non-secure and secure domains. Same for Cortex-M23. |
| Ok, so I’m not familiar with whether the non-banked registers include what’s in the 3-stage pipepline. The v7M Technical reference manual recommends issuing an ISB() when toggling the priviledge bit to clear priviledged instructions from the pipeline. This is not necessary for TrustZones because the pipeline is considered a non-banked register? Or am I misunderstanding… | Yes the TrustZone piece has separate registers that are banked separate from the non-secure zone. The shared registers when using the attribute))((cmse_nonsecure_entry)) will clear the banked registers upon returning to the non-secure world. |
| Interesting, thanks. So the 3-stage pipeline isn’t shared between the secure and non-secure states? If not, does this mean that there’s a performance hit for whichever state doesn’t use the pipeline? Or are there two separate pipelines for each state? | There is a single pipeline for the processor. secure and non-secure code cannot run concurrently. So I think you misunderstood. The pipeline is “shared”. |
| Thank you – re the pipeline: If you move from secure to non-secure and there are two instructions from the secure world in the 3-stage pipeline, do you have to issue an ISB to clear them? v7m suggests you do this when switching between priviledged and non privileged execution mode. | transitioning from secure to non-secure code does not require ‘ISB’. A simple branch instruction suffice. The target branch address must contain a ‘SG’ <secure gateway> instruction to allow entry into secure domain. The function return automatically clears registers so as not to leak ‘secure’ data to the non-secure world. |
