Single MCU Solution for Safety-Related Applications Using TrustZone

TrustZone® (TZ) technology often gets associated with safety-related applications, like protecting cryptographic keys or hardware resources from unauthorized exposure. By reducing the attack surface and strictly enforcing the access policy, it is possible to create an on-chip environment safeguarding the misuse of such valuable resources.

Generalizing from the security-focused use case, what TZ really provides is hardware isolation of resources within a processing context, so generally applicable to other environments, where IEC 60730 normative requirements must be fulfilled. Those norms define several classes or categories of appliances and strive for the safe operation of automatic electrical controls within a household. The classification in categories A, B, or C is tied to the type of appliance and the threats it might pose to human beings during operation. Class A products do not provide potentially harmful features or functions. Class B appliances need to implement control functions that can prevent an unsafe operation of the controlled equipment. A washing machine is a good example, with sensors to stop operation as soon as the appliance temperature exceeds the safe operational limit, or a door lock preventing an operator from accessing the loading drum during an ongoing washing cycle. The related software includes code meant to prevent hazards if a hardware fault occurs.

Class C is more demanding since the control functions must prevent especially dangerous and harmful hazards like explosions. A typical example of such a system is an automatic burner control. Such type of software requires more strict controls, as deep and thorough diagnostics are necessary since a fault in the safety critical software routine will result in a hazard. This is because a failure in one function is not assumed to be mitigated by intervention of another software safety routine, or by redundant hardware. Several annexes to the main norm define the software evaluation requirements, down to the electronics controls. Broadly speaking, the norms discuss the embedded components (i.e., system implementation aspects) that must be tested to comply with Class B and Class C. At the same time, the norms list a few measures required to ensure safe and reliable operation.

Within the RA6 and RA4 MCU family, Arm® Cortex®-M33 CPU-based devices provide support for Arm TrustZone-M. TrustZone technology defines a secure or non-secure state within the CPU context, isolating user threads and interrupts from executing while in the non-secure state from those executing in the secure state. A secure program (located in an executable memory region marked as secure) can access both secure and non-secure data and executes only while the CPU is in a secure state. A non-secure program (in non-secure executable memory) can access non-secure data only and executes only while the CPU is in a non-secure state; any violating transaction is blocked, and a secure fault exception (interrupt) is issued. The non-secure environment can interact with the secure portion by using a controlled, user-defined, non-secure callable functional interface. The RA hardware supports a convenient granularity for defining the TZ memory section boundaries, to optimize their allocation.

At the system level, the asset isolation policy is similarly applied to on-chip memories, bus initiators like direct memory access (DMA) controllers, peripherals, and I/O ports. All bus initiators feature security attributes that allow allocation of their operation within one of the two domains, identifying each generated transaction as either secure or non-secure. Illegal transactions generate system exceptions for appropriate user-configurable error handling. To ensure system integrity, all transfers violating the policy are either rejected upfront or stopped as soon as the violation is detected.

On the receiver side, TZ filters are implemented to monitor all bus transactions, allow the legitimate ones to proceed, and block the non-allowed ones, according to the user-defined system configuration. In addition, every peripheral functional interface (memory mapped registers) has dedicated security attributes for either all its registers, for each channel (applicable to multi-channel instances), or at the individual bit level (for shared system level settings, or general-purpose I/O modules). Complementary hardware features like application watchdogs, independent watchdogs, and MPUs, assist the developer in enhancing system resilience and supporting the safety-relevant Class C software in monitoring the operation of the non-safety-related application portion. This is mandatory to react appropriately and ensure the system is always in a safe and controlled state of operation.

As for the configuration of the application and the drivers, RENESAS has developed a clever and simple-to-use tool, integrated within the e2 studio development environment, to guide the user in creating a secure and non-secure project in a few easy steps. Under the hood, the tool takes care of generating all appropriate compiler primitives and macros necessary to handle the configured non-secure callable interfaces and function stubs. It also assists in allocating the memory layout automatically in a size-optimized way and generating the secure and non-secure sections for later seamless programming of the application image.

Noticeably, TrustZone as a tool by itself does not comply with the Class C standard requirements. Just using TrustZone does not mean creating or being compliant with the requirements of a software system for Class A and C; the final software evaluation and the testing according to abnormal operation (operation under fault conditions of hardware) is not substituted by simply using TrustZone. It is still the manufacturer’s responsibility to use the TrustZone and MCU environment correctly and completely to fulfill the requirements of the standard.

However, TrustZone as a tool and its implementation on the RA family of microcontrollers can support the software manufacturer in creating a software system of software Class A and C within one single microcontroller. This statement has been confirmed by VDE, and the respective test report (about the result of a singular investigation carried out on the product submitted, of which a sample was tested) found the accordance with the thereafter listed [Standards] or clauses from the relevant [Standards], see footnote.

Renesas has created a technical note that details how the RA MCU features can support the creation of a Class C application. Developers can contact Renesas to get more information on this solution advancement and get the full test report information.

[Standards] IEC 60335-1:2010, /AMD1:2013, /AMD2:2015 Annex R; EN 60335-1:2012+AC+A11+A13+A1+A2+A14:2019; EN 60335-1:2012/A15:2021 Annex R; IEC 60730-1:2013, /AMD1:2015, /AMD2:2020 Annex H; EN 60730-1:2016+A1:2019, EN 60730-1:2016/A2:2022 Annex H