This documet is an introduction about TrustZone on the LPC55S6x devices. LPC55S6x MCU platform and general-purpose blocks The LPC55S69 has one 100-MHz Cortex-M33 core with TrustZone, MPU, FPU, and SIMD and another 100-MHz Cortex-M33 without security features enable. Lets remark that the LPC55Sxx family has another LPC55S66 that only implements a single 100-MHz core. There are two coprocessors on core 0, a DSP accelerator called PowerQuad, and a crypto engine called CASPER. The core platform has a multilayer bus matrix that allows simultaneous execution from both cores and parallel access of the other masters to peripherals and memories. The memory on chip includes up to 640 KB of Flash, up to 320 KB of RAM, and 128 KB of ROM. Timers include 5 - 32-bit timers, a SCTimer/PWM, a multi-rate timer, a windowed watchdog timer, Real Time Clock (RTC), and a micro timer. Each core has its own systick timer. Communication interfaces include a USB high-speed with on-chip HS PHY, a USB full-speed that can run crystal-less, two SDIO interfaces to support WIFI and SD cards at the same time, 1 high-speed SPI with up to 50-MHz clock rate, and 8 Flexcomms with support of up to 8 SPI, I2C, UART, or 4 I2S. The analog system includes a 16-channel 16-bit ADC that samples at 1 MSPS, an analog comparator, 16-channel capacitive touch controller, and a temperature sensor. Other modules include a programmable logic unit, a buck DC-DC converter, operating voltage from 1.71 to 3.6 V over a temperature range from -40 to 105 °C. What is TrustZone? In recent years, the Internet of Things (IoT) has become a hot topic for embedded system developers. IoT system products have become more complex, and better solutions are needed to ensure system security. ARM® TrustZone® technology is a System on Chip (SoC) and CPU system-wide approach to security. The TrustZone® for ARMv8-M security extension is optimized for ultra-low power embedded applications. It enables multiple software security domains that restrict access to secure memory and I/O to trusted software only. TrustZone® for ARMv8-M: Preserves low interrupt latencies for both secure and non-secure domains Does not impose code overhead, cycle overhead or the complexity of a virtualization based solution Introduces efficient instructions for calls to the secure domain with minimal overhead TrustZone® is a technology available in Cortex M23 and Cortex M33. TrustZone® provides the means to implement separation and access control to isolate trusted software and resources to reduce the attack surface of critical components. The created trusted firmware can protect trusted operations and is ideal to store and run the critical security services. The code should also protect trusted hardware to augment and fortify the trusted software. This includes the modules for hardware assists for cryptographic accelerators, random number generators, and secure storage. Best practices demand that that this code be small, well-reviewed code with provisions of security services. The LPC55S66 and LPC55S69 have implemented core 0 as a Cortex-M33 with full TEE and TrustZone® support enabled. The LPC55S69 has a second Cortex-M33 (core 1) that does not implement the secure environment with TZ. Isolation is just the foundation. Security is about layers of protection, adding in further hardware and software to create more layers. Features of TrustZone® technology: Allows user to divide memory map into Secure and Non-Secure regions Allows debug to be blocked for Secure code/data when not authenticated CPU includes Security Attribution Unit (SAU) as well as a duplication of NVIC, MPU, SYSTICK, core control registers etc. such that Secure/Non-Secure codes can have access to their own allocated resources Stack management expands from two stack pointers in original Cortex-M (Main Stack Pointer (MSP) and Process Stack Pointer (PSP)) to four, providing the above pair individually to both Secure and Non-Secure Introduces the concept of Secure Gateway opcode to allow secure code to define a strict set of entry points into it from Non-secure code Secure and non-secure memory TrustZone® technology divides the system into two states, safe (S) and non-secure (NS), and can switch between the two states through corresponding commands. The CPU states can be secure privilege, secure non-privilege, privilege (Handler), or non-privilege (Thread). The Secure memory space is further divided into two types: Secure and Non-secure Callable(NSC). Below are the feature/properties of Trustzone memory regions ( S, NS, NSC 😞 Secure (S) - For Secure code/data − Secure data can only be read by secure code − Secure code can only be executed by CPU in secure mode Non-Secure (NS) – For non-Secure code/data − NS Data can be accessed by both secure state and non-secure state CPU − Cannot be executed by Secure code Non-Secure Callable (NSC) − This is a special region for NS code to branch into and execute a Secure Gateway (SG) opcode. Attribution Units Combination of Security SAU and IDAU assign a specific security attribute (S, NS, or NSC) to a specific address from the CPU0. Device Attribution Unit (DAU) connects to CPU0 via IDAU interface as show the following Figure. Access from CPU0, dependent on its security status and the resultant security attribute set by the IDAU and SAU, is then compared by the secure AHB Controller to a specific checker which marks various access policies for memory and peripherals. All addresses are either secure or non-secure. The SAU inside of the ARMv8-M works in conjunction with the MPUs. There are 8 SAU regions supported by LPC55S69. Secure and non-secure code runs on a single CPU for efficient embedded implementation. A CPU in a non-secure state can only execute from non-secure program memory. A CPU in a non-secure state can access data from both NS memory only. For the secure, trusted code, there is a new secure stack pointer and stack-limit checking. There are separate Memory Protection Units (MPUs) for S and NS regions and private SysTick timers for each state. The secure side can configure the target domain of interrupts. The NXP IDAU (Implementation specific Device Attribution Unit) implementation of ARM TrustZone for core0 involves using address bit 28 to divide the address space into potential secure and non-secure regions. Address bit 28 is not decoded in memory access hardware, so each physical location appears in two places on whatever bus they are located on. Other hardware determines which kinds of accesses (including non-secure callable) are allowed for any address. The IDAU is a simple design using address bit 28 to allow aliasing of the memories in two locations. If address bit 28 is = 0 the memory is Non-Secure. If address bit 28 = 1 the memory is Secure. The SAU allows 8 memory regions and allow the user to override the IDAU’s fixed Map, to define the non-secure regions. By default, all memory is set to secure. At least one ASU descriptor should be used to make IDAU effective. If either IDAU or SAU marks a region, then that region is secure. NSC area can be defined in NS region of the IDAU. For example a designer could use bit [28] of the address to define if a memory is Secure or Non-secure, resulting in the following example memory map. Simple IDAU, without creating a critical timing path. (CM33 does allows little for IDAU function) Addresses 0x0000_0000 to 0x1FFF_FFFF are NS, Addresses 0x2000_0000 to 0xFFFF_FFFF If Address Bit_28 = 0 Non-Secure If Address Bit_28 = 1 Secure All peripherals and memories are aliased at two locations. The SAU define region numbers for each of the memory regions. The region numbers are 8-bit, and are used by the Test Target(TT) instruction to allow software to determine access permissions and security attribute of objects in memory. The number of regions that are included in the SAU can be configured to be either 0, 4 or 8. Note: When programming the SAU Non-secure regions, you must ensure that Secure data and code is not exposed to Non-secure applications. Security state changes The system boots in secure state and can change security states using branches as summarized in the following Figure. Transitions from secure to non-secure state can be initiated by software through the use of the BXNS and BLXNS instructions that have the Least Significant Bit (LSB) of the target address unset. Note: The M profile architecture does not support the A32 instruction set. This allows the LSB of an address to denote the security state. Transitions from non-secure to secure state can be initiated by software in two ways: A branch to a secure gateway. A branch to the reserved value FNC_RETURN. A secure gateway is an occurrence of the Secure Gateway instruction (SG) in the Non-Secure Callable (NSC) region. When branching to a secure gateway from non-secure state, the SG instruction switches to the secure state and clears the LSB of the return address in lr. In any other situation the SG instruction does not change the security state or modify the return address. A branch to the reserved value FNC_RETURN causes the hardware to switch to secure state, read an address from the top of the secure stack, and branch to that address. The reserved value FNC_RETURN is written to lr when executing the BLXNS instruction. Security state transitions can be caused by hardware through the handling of interrupts. Those transitions are transparent to software and are ignored in the remainder of this document. The TT instruction The ARMv8-M architecture introduces the Test Target instruction (TT). The TT instruction takes a memory address and returns the configuration of the Memory Protection Unit (MPU) at that address. An optional T flag controls whether the permissions for the privileged or the unprivileged execution mode are returned. When executed in the secure state the result of this instruction is extended to return the Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU) configurations at the specific address. The MPU is banked between the two security states. The optional A flag makes the TT instruction read the MPU of the non-secure state when the TT instruction is executed from the secure state. The TT instruction is used to check the access permissions that different security states and privilege levels have on memory at a specified address. You can find more useful information about ARM® TrustZone®, in the following links: https://developer.arm.com/ip-products/security-ip/trustzone https://www.nxp.com/docs/en/application-note/AN12278.pdf http://www.keil.com/appnotes/files/apnt_291.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf
View full article
