Overview of ARMv8 System Security

Security in ARMv8-A Systems

A secure or trusted operating system protects sensitive information within the system, such as passwords and credit card authentication information stored by users, from attacks.

Security is defined by the following principles:

• Confidentiality: Protects sensitive information on the device from unauthorized access. This can be achieved through various methods, such as passwords and encryption keys.

• Integrity: Uses public keys to protect sensitive information from being modified.

• Availability: Ensures that access to sensitive information is authorized, utilizing firmware updates to detect unauthorized access.

For example, a trusted system stores passwords for mobile payments, digital certificates, etc. Achieving absolute security in an open system is difficult because users may download various software onto mobile devices, including potentially malicious code that could compromise the system.

Software and hardware attacks can be categorized as follows:

• Software Attacks: Malware attacks often do not require access to the actual device and can exploit vulnerabilities in the operating system or applications to carry out remote attacks.

• Simple Hardware Attacks: Most hardware attacks are non-destructive and require physical access to the actual device, using common tools such as JTAG and logic probes.

• Advanced Hardware Attacks: These attacks require complex and expensive tools, such as focused ion beam (FIB) technology or power analysis techniques, and are more commonly used against smart card devices.

TrustZone technology is specifically designed to combat software attacks. TrustZone can also defend against some simple hardware attacks.

TrustZone Hardware Architecture

The TrustZone architecture provides system designers with a method to help protect the system. Even low-level programmers should understand the architecture design of TrustZone.

The ARM security extension model allows system developers to partition hardware devices and software resources so that they can exist in both the secure subsystem’s Secure World and the other subsystem’s Normal World.

The ARM manual uses Secure World and Non-secure World to indicate the security state of the system. Non-secure World does not imply security vulnerabilities; it refers to the normally operating system, that is, the Normal World. Typically, there exists a master-slave relationship between Secure World and Non-secure World. The code in Secure World can only be executed when called by the operating system via the SMC (Secure Monitor Call) instruction.

The memory and functionalities of Non-secure World can also be accessed by Secure World.

The secure monitor manages the switching between Secure World and Non-secure World, similar to context switching in an operating system. It ensures that the current environment is fully preserved when leaving Secure World and can be correctly restored when the processor switches back to Secure World.

TrustZone is a supplementary extension to the ARM architecture, meaning that a processor can run code for both Secure World and Non-secure World simultaneously. If the Secure World is configured to allow interrupt peripherals, then code from Secure World and Non-secure World can call each other.

The secure monitor provides an interface between Secure World and Non-secure World. For robustness, the code of the secure monitor should execute in a context where interrupts are disabled. Writing a reentrant secure monitor can be complex and does not provide many benefits.

Additionally, the execution of Secure World and Non-secure World programs can also be performed in a multitasking parallel manner like an operating system. While the resources accessible during the execution of Secure World programs are completely independent of Non-secure World, the two worlds can also yield to each other to achieve multitasking parallelism.

Like firmware or any other system software, software in Secure World should minimize its impact on other parts of the system. For example, the code execution in Secure World should avoid consuming excessive time. Interrupts in Non-secure World should be passed to Normal World as quickly as possible, which helps ensure good responsiveness of Normal World software.

The memory system is divided by an additional bit called the NS bit, which indicates whether the accessed memory is from Secure World or Non-secure World. This bit is added to all memory system transactions, including cache tags and accesses to system memory and peripherals. The NS bit can provide different physical address spaces for Secure World and Non-secure World.

Software running in Normal World can only access memory in a Non-secure manner. This is because in memory transactions generated by Normal World, the NS bit is always set to 1, regardless of the settings in the translation tables of Normal World. Software running in Secure World only performs Secure memory accesses but can also use the NS and NSTable flags in the translation tables to access specific memory in a Non-secure manner.

If a Non-secure access is made to cache data marked as secure, it will result in a cache miss. If a Non-secure access is made to external memory marked as secure, it will typically return an error response to the kernel.

EL3 has its own translation tables managed by TTBR0_EL3 (Translation Table Base Register) and TCR_EL3 (Translation Control Register). In secure state, only stage 1 translations are allowed, with no TTBR1_EL3 register. The EL1 translation table registers are not stored between secure states, so the values of TTBR0_EL1, TTBR1_EL1, and TCR_EL1 must be saved and restored for each world as part of the secure monitor context switching operation.

This allows each world to have its own set of local translation tables. The mappings of Secure World are hidden and protected from Normal World. The translation tables of Secure World include NS and NSTable bits, which determine whether access to physical address space in Secure World and Non-secure World is allowed.

Entries for Secure and Non-secure can coexist in the cache and TLB. When switching between different worlds, the cache does not invalidate. Normal World can only perform Non-secure accesses, so it can only hit caches marked as Non-secure. Secure World can generate both Secure and Non-secure accesses, and if the security state changes during an access, there may also be cache management.

Entries in the TLB record which world generated them. Although Non-secure state can never operate on Secure data, Secure World can allocate NS rows to buffers. Additionally, cache enabling and disabling are different at each exception level. Cache control is independent for both worlds, but not independent across all exception levels. Therefore, EL0 cannot directly enable or disable the cache, while EL2 can override the behavior of Non-secure EL1.

Interaction Between Secure World and Non-secure World

If you are writing code in a system that includes security services, understanding the interaction between Secure World and Non-secure World is useful. A typical operating system will contain a lightweight kernel or Trusted Execution Environment (TEE). For example, encryption services run in Secure World. It can interact with the operating system in Normal World, which can access Secure World via SMC calls. In this way, Normal World can access Secure World without worrying about exposing encryption keys.

Generally speaking, developers do not interact directly with the security extension components, TEE, or trusted services, but access Secure World through APIs provided by Normal World (e.g., authenticate()).

The following diagram illustrates the interaction between Normal World and Secure World in the form of application API calls. The API passes through system calls to the TrustZone Driver and then is relayed to TEE via the secure monitor.

This calling method frequently passes data between Secure World and Normal World.

For example, there is a signature checker in Secure World. Normal World can request Secure World to verify the signature of downloaded updates using SMC calls. If Secure World needs to access memory used by Normal World, it can use the NS bit in its translation table descriptor to ensure it accesses the data in a Non-secure manner.

This is important because the content related to the requested data may already be in the cache, as accesses performed by Secure World are always marked as Non-secure addresses. Security attributes can be considered as an additional address bit. If the kernel attempts to read data using secure memory access, it will not hit Non-secure data that is already in the cache.

If you are a programmer who usually only interacts with Normal World, you can ignore what happens in Secure World, as its operations are hidden from you. A side effect is that interrupt latencies may slightly increase. Secure World can be completely blocking, so if an interrupt occurs while in Secure World, it may block interrupts in Normal World. However, this can be considered negligible compared to the overall latency of a typical operating system. The impact of this issue on Normal World depends on the architectural design of the Secure World operating system.

Switching Between Secure and Normal Worlds

In the security extension of ARMv7, software uses Monitor mode to switch between Secure and Non-secure states. This mode is the same as other privileged modes in Secure state. In ARMv8-A processors, AArch32 corresponds to ARMv7-A.

For the ARMv8 architecture, when EL3 uses AArch32, the ARMv8 architecture corresponds to ARMv7 to ensure full compatibility, and all privileged modes in secure state are considered to be at EL3.

The security model of AArch32 is shown in the following diagram. In this case, EL3 is AArch32, providing a secure operating system and monitor.

The following diagram shows the security model when EL3 executes AArch64 to provide a secure monitor. EL1 is used for the secure operating system. When EL3 uses AArch64, EL3 is responsible for executing the code that switches between Non-secure state and Secure state.

To maintain consistency with AArch32, the EL1 and EL0 of Secure state have different virtual address spaces from those of Non-secure state. This allows the code running in Secure state of the AArch32 32-bit architecture to be used in the 64-bit operating system running in Non-secure state.

When the execution of Normal World stops and the execution of Secure World begins, context switching occurs between them by executing the Secure Monitor Call (SMC) instruction or through hardware exception mechanisms (such as interrupts or asynchronous aborts). ARM processors have two types of interrupts: FIQ and IRQ.

Interrupts are also supported in Secure World, where the principle is to redirect interrupts generated in Secure World to EL3, regardless of the current DAIF field. However, these controls only differentiate between the major types of interrupts: IRQ, FIQ, and asynchronous aborts. More detailed control requires dividing interrupts into Secure and Non-secure groups. To achieve this, support from GIC is required, which has features to support partitioning into different groups.

A typical example is that FIQ is used as Secure interrupts by mapping secure interrupt sources to FIQ within the interrupt controller. At the same time, the related peripherals and interrupt controller registers must be marked as accessible only in a secure manner to prevent Normal World from reconfiguring these interrupts.

The implementation of security extensions typically has a lightweight trusted kernel hosting security services (such as encryption) in Secure World. A complete operating system runs in Normal World and can access security services using SMC instructions. In this way, Normal World can access service functionalities without risking exposure of sensitive data in code executed in Normal World.

Security Issues in Clusters

Each core in a cluster system has the same security features. Any number of cores in a cluster can execute in Secure World at any point in time, and the cores can transition independently between worlds. The register controls whether Normal World code can modify the settings of the Snoop Control Unit (SCU). Similarly, the GIC allocating priority interrupts across the cluster must be configured for secure state.

Secure systems also control the availability of debugging provisions. You can configure independent hardware debugging for Normal Worlds and Secure Worlds, such as JTAG debugging and trace control, so that there is no leakage of information about the trusted system. You can control hardware configuration options through a secure peripheral, or you can connect them via hardware and control them using the following signals.

• Secure Privileged Invasive Debug Enable (SPIDEN): JTAG debug.
• Secure Privileged Non-Invasive Debug Enable (SPNIDEN): Trace and Performance Monitor.

Conclusion

1. TrustZone is a security extension model of the ARM architecture that can be used in any ARM processor.

2. Normal World accesses Secure World through SMC instructions. The secure monitor manages the switching between Normal World and Secure World. The code of the secure monitor executes in a context with interrupts disabled.

3. The NS bit in memory system transactions indicates whether the accessed memory is from Secure World or Normal World. Normal World can only perform Non-secure accesses, while Secure World can perform both Secure and Non-secure accesses simply by changing the NS bit.

4. The translation tables of Secure World and Non-secure World are independent, with the translation table of Secure World protected from Normal World.

5. ARMv8-A can be compatible with both 32-bit and 64-bit TrustZone. When ARMv8-A runs AArch32 TrustZone, it corresponds to ARMv7-A. The main difference lies in EL3, where ARMv7-A provides Secure Monitor and Secure OS, while ARMv8 only provides Secure Monitor.

References

security_in_an_armv8_system_100935_0100_en