Click the blue "Arm Selected" in the upper left corner and select "Set as Favorite"1. Background
With the advancement of technology, the trend for security needs has become increasingly evident. ARM has been continuously adjusting and updating its new architectures, many of which are related to security. Below are some architectures related to security.
As part of ARM’s security architecture, TrustZone was first introduced in December 2008 when ARM released the TrustZone technology white paper. In 2013, Apple launched the first iPhone with fingerprint unlocking: the iPhone 5s, which utilized the Secure Enclave technology to ensure the security of fingerprint information, deeply customizing the ARM TrustZone architecture. This was likely the first time TrustZone technology entered the public eye. Today, TrustZone technology has become an important foundational technology in the field of mobile security. You may not understand its technical principles, but it has been silently protecting your fingerprint information, account passwords, and various sensitive data. Below is a block diagram of a fingerprint system under the TrustZone architecture, which has been a popular software framework in recent years (2015-present).
2. Overview of ARM TrustZone Security Extensions
From the above, we know that ARM TrustZone does not specifically refer to a piece of hardware or software, but rather a technical architecture. In SoCs that support ARM TrustZone, each sub-module must be designed according to ARM TrustZone technology. Below is a design block diagram of an SoC under the TrustZone architecture.
Among them:
(1) Extension of the AMBA-AXI bus, adding secure read and write address lines: AWPROT[1] and ARPROT[1](2) Extension of the processor (or master), adding the SCR.NS bit within the ARM Core, allowing operations initiated by the ARM Core to be marked as “secure access” or “non-secure access”(3) TZPC extension, adding TZPC at the AXI-TO-APB end to configure the permissions of the APB controller (also called secure controller). For example, if the efuse (OTP Fuse) is configured as a secure attribute, then accesses initiated by the processor as non-secure will be denied, and illegal accesses will return an error to the AXI bus.
(4) TZASC extension, adding a memory filter above the DDRC (DMC). Currently, TZC400 is commonly used, or an IP designed by the SoC manufacturer, also called MPU, or integrated within the DMC. Its role is generally to configure DDR permissions. If a certain region in DDR is configured as a secure attribute, then accesses initiated by the processor as non-secure will be denied.
(5) Support for security extensions by MMU/Cache. In the software architecture design, it is divided into: Non-secure EL0&1 Translation Regime and Secure EL0&1 Translation Regime, meaning that the normal world and secure world use different Translation Regimes, which actually use different TTBRx_ELn registers and different page tables. Note: In armv7, TTBRx is banked by Security State, meaning that there is a set of such registers in both the secure and non-secure worlds, allowing Linux and TEE to maintain their own memory page tables. In armv8/armv9, TTBRx_EL0 and TTBRx_EL1 are no longer banked, but during world switch, the CPU context is switched in ATF, so from the hypervisor or OS perspective, there are still two sets of different TTBRx_ELn registers, with Linux and TEE each having their own page tables. In the TLB, a Non-secure attribute bit is added to each entry, indicating whether the current cache is secure or non-secure; cache extension: in the cache entry TAG, there is a NON-Secure Identifier indicating whether the physical address of the current cached data belongs to non-secure or secure.(6) Support for security extensions by GIC. In versions gicv2 and gicv3, support for security extensions has been added. For example, in gicv3, interrupts are divided into group0, secure group1, and non-secure group1. Under software configuration, interrupts from group0 and secure group1 will not be targeted to REE (Linux) for processing.
3. Detailed Explanation of ARM TrustZone Security Extensions
3.1 AMBA-AXI Support for TrustZone
ARPROT[2:0] and AWPROT[2:0] are the permission signals in the read and write channels, respectively. For example, BIT[1] indicates whether a secure read or secure write operation is being performed.
3.2 SCR.NS Bit of the Processor
<span><span><span>SCR_EL3</span></span></span><span><span><span>.</span></span></span><span><span><span>NS</span></span></span> indicates the current security state of the processor, where NS=1 indicates non-secure, and NS=0 indicates secure.
3.3 Introduction to TZC400 and TZPC
The TZC400 is positioned between the core and the (DMC) DDR, acting as a memory filter. The TZC400 can generally configure 8 regions (including the special region 0, which can be considered as 9), and permissions can be configured for each region. For example, if a region is configured as secure RW, then when a non-secure master attempts to access that memory, it will be blocked by the TZC.
3.4 MMU Support for TrustZone
In the software architecture design, it is divided into: Non-secure EL0&1 Translation Regime and Secure EL0&1 Translation Regime, meaning that the normal world and secure world use different Translation Regimes, which actually use different TTBRx_ELn registers and different page tables. Additionally, the page tables used by the MMU also have NS bits.
The Non-secure Translation Regime can only translate page table entries with NS=1, while the secure Translation Regime can translate both NS=1 and NS=0 page table entries. This means that the secure page table can map both non-secure and secure memory, while the non-secure page table can only map non-secure memory; otherwise, an error will occur during translation.
In the Page Descriptor (page table entry), there is an NS bit (BIT[5]) indicating whether the currently mapped memory is secure or non-secure:
3.5 Cache Support for TrustZone
As shown below, taking the Cortex-A78 as an example, in the L1 Data Cache TAG, there is an NS bit (BIT[33]) indicating whether the current cached cacheline is secure or non-secure.
3.6 TLB Support for TrustZone
As shown below, taking the Cortex-A78 as an example, in the L1 Data TLB entry, there is an NS bit (BIT[35]) indicating whether the current cached entry is secure or non-secure.
3.7 GIC Security Interrupts
In gicv2/gicv3, support for secure interrupts has been added, configured as follows: (1) Group division (GICD_IGROUPRn) — gicv2◾group0: secure interrupts, driven by nFIQ ◾group1: non-secure interrupts, driven by nIRQ
(2) Group division (GICD_IGROUPRn)— gicv3◾group0: secure interrupts ◾non-secure group1: non-secure interrupts ◾secure group1: secure interrupts
4. Changes Brought by ARM TrustZone Technology to Software
ARM TrustZone technology has brought changes to the software framework.
4.1 EL3 is AArch64:
4.2 EL3 is AArch32:
Understanding AArch32 and AArch64 secure monitors:
-
If both secure OS and monitor are 64-bit, the secure OS runs at EL1, and the monitor runs at EL3;
-
If both secure OS and monitor are 32-bit, both run at EL3 (secure OS in SVC mode, monitor in SVC mode), sharing the same page table;
-
If the monitor is 64-bit and the secure OS is 32-bit, then the secure OS runs in SVC mode (EL1), and the monitor runs at EL3, and they do not share the same page table.
4.3 armv7:
| GoodCourseRecommendation | “From Beginner to Master of Armv8/Armv9 Architecture” Three Sessions |
| “TrustZone/TEE/Security from Beginner to Master” Standard Edition | |
| “Arm Selected – Platinum VIP Course“ | |
| 🌍Consult via WeChat: sami01_2023 |