Click the blue "Arm Selected" at the top left corner and select "Set as Star"1. Background:
With the advancement of technology, the trend for security needs is becoming 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 
TrustZone, as part of ARM’s security architecture, was first introduced by ARM in December 2008 with the release of 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 the first time TrustZone technology came into the public eye. Today, TrustZone technology has become an essential foundational technology in the mobile security field. 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 under the TrustZone architecture, which has been a popular software framework in recent years (2015-present).
2. Introduction to ARM TrustZone Security Extensions
From the above, we know that ARM TrustZone does not refer to a specific 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 
:
-
(1) Extension of 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 in 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, used to configure the permissions of the APB controller (or secure controller). For example, if the efuse (OTP Fuse) is configured as secure, then non-secure access initiated by the processor will be denied, and illegal access will return an error to the AXI bus.
-
(4) TZASC extension, adding a memory filter above DDRC (DMC). Currently, TZC400 is commonly used, or an IP designed by the SoC vendor, or integrated within the DMC. Its role is generally to configure DDR permissions. If a certain region of DDR is configured as secure, then non-secure access initiated by the processor will be denied.
-
(5) Support for security extensions by MMU/Cache. In software architecture design, it is divided into: Non-secure EL0&1 Translation Regime and Secure EL0&1 Translation Regime, meaning that different Translation Regimes are used for the normal world and secure world, 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 secure and non-secure worlds, allowing Linux and TEE to maintain their respective memory page tables. In ARMv8/ARMv9, TTBRx_EL0, TTBRx_EL1 are no longer banked, but during world switch, the context is switched in ATF, so from the hypervisor or OS’s 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 to indicate 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 current cached data’s physical address belongs to non-secure or secure.
-
(6) Support for security extensions by GIC. In GICv2 and GICv3 versions, support for security extensions is 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 Anatomy of ARM TrustZone Security Extensions
3.1 Support of AMBA-AXI for TrustZone
ARPROT[2:0] and AWPROT[2:0] are the permission signals in the read and write channels, for example, BIT[1] indicates whether it is a secure read or secure write operation.
3.2 SCR.NS Bit of Processor
SCR_EL3.NS 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
TZC400 is positioned between the core and (DMC) DDR, acting as a memory filter. TZC400 can generally configure 8 regions (including special region 0, or 9 in total), and permissions can be configured for each region. For example, if a region is configured as secure RW, non-secure masters attempting to access this memory will be blocked by TZC. 
3.4 Support of MMU for TrustZone
In 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 table used by the MMU also has an NS bit. The Non-secure Translation Regime can only translate NS=1 page table entries, while the Secure Translation Regime can translate both NS=1 and NS=0 page table entries. This means that secure page tables can map non-secure or secure memory, while non-secure page tables 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 current mapped memory is secure or non-secure: 
3.5 Support of Cache for TrustZone
As shown below, taking the Cortex-A78 as an example, the L1 Data Cache TAG contains an NS bit (BIT[33]), indicating whether the current cached cacheline is secure or non-secure 
3.6 Support of TLB for TrustZone
As shown below, taking the Cortex-A78 as an example, the L1 Data TLB entry contains an NS bit (BIT[35]), indicating whether the current cached entry is secure or non-secure 
3.7 GIC Security Interrupts
In GICv2/GICv3, security interrupts are supported, configured as follows: (1) Grouping (GICD_IGROUPRn) — gicv2◾group0: secure interrupts, driven by nFIQ ◾group1: non-secure interrupts, driven by nIRQ
(2) Grouping (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 monitor:
-
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, they both run at EL3 (secure OS in SVC mode, monitor in SVC mode), sharing the page table;
-
If the monitor is 64-bit and the secure OS is 32-bit, the secure OS runs in SVC mode (EL1), and the monitor runs at EL3, and they do not share the page table.
4.3 ARMv7:
