Overview of ARMv8 System Security

Security in ARMv8-A Systems

A secure or trusted operating system protects sensitive information in the system, such as user-stored passwords and credit card authentication information from attacks.

Security is defined by the following principles:

• Confidentiality: Protect sensitive information on the device to prevent unauthorized access. This can be achieved through various means, such as passwords and encryption keys.

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

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

For example, a trusted system stores mobile payment passwords, digital certificates, etc. In an open system, achieving absolute security is difficult because users may download various software to mobile devices, including malicious code that may tamper with the system.

Software and hardware attacks can be classified into the following categories:

• Software attacks: Malware attacks typically do not require physical access to the device and can exploit vulnerabilities in the operating system or applications for remote attacks.

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

• Professional 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 withstand 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 architectural 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. The Non-secure World does not imply security vulnerabilities; it refers to the normally operating system, i.e., the Normal world. Typically, there is a master-slave relationship between the Secure World and Non-secure World. The code in the Secure World can only be executed when called by the operating system through the SMC (Secure Monitor Call) instruction.

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

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

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

The Secure monitor provides the interface between the Secure World and Non-secure World. For the robustness of the program, the code of the Secure monitor should be executed in a context with interrupts disabled. Writing a reentrant Secure monitor can be complex and does not bring much benefit.

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

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

The memory system is divided by an additional bit called the NS bit. This bit indicates whether the accessed memory is 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 the Normal World can only access memory in a Non-secure manner. This is because in memory transactions generated by the Normal World, the NS bit is always set to 1, regardless of the settings in the translation table of the Normal World. Software running in the Secure World only performs Secure memory accesses but can also use the NS and NSTable flags in the translation table to access specific memory in a Non-secure manner.

If a Non-secure access is made to cache data marked as secure, it will cause a cache miss. If a Non-secure access is made to external storage marked as secure, it typically returns an error response to the kernel.

EL3 has its own translation table, managed by TTBR0_EL3 (Translation Table Base Register) and TCR_EL3 (Translation Control Register). In a secure state, only stage 1 translations are allowed, and there is 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 switch operation.

This means that each world has its own set of local translation tables. The mapping of the Secure World is hidden and protected from the Normal World. The translation table of the Secure World includes NS and NSTable bits, which determine whether the physical address space of the Secure World and Non-secure World can be accessed.

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

Entries in the TLB record which world generated them. Although the Non-secure state can never operate on Secure data, the Secure World can assign NS entries to the buffer. Additionally, the enabling and disabling of the cache are different at each exception level. Cache control is independent for both worlds but not independent for 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 coding in a system that includes security services, understanding how the Secure World and Non-secure World interact is useful. A typical operating system will include a lightweight kernel or Trusted Execution Environment (TEE). For example, encryption services run in the Secure World. It can interact with the operating system in the Normal World, which can access the Secure World via SMC calls. In this way, the Normal World can access the Secure World without worrying about exposing encryption keys.

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

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

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

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

This is important because the content related to the request for data may already be in the cache, as accesses made by the Secure World will be marked as Non-secure addresses. The security attribute can be considered as an additional address bit. If the kernel attempts to read data using secure memory access, it will not hit the Non-secure data already in the cache.

If you are a programmer who typically only interacts with the Normal world, you can ignore what happens in the Secure World because its operations are hidden from you. One side effect is that interrupt latency may slightly increase. The Secure World can be fully blocking, so if an interrupt occurs while in the Secure World, it may block interrupts in the Normal world. However, compared to the overall latency of a typical operating system, this can be ignored. The impact of this issue on the 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 the Secure state. In ARMv8-A processors, AArch32 is equivalent to ARMv7-A.

For the ARMv8 architecture, when EL3 uses AArch32, the ARMv8 architecture is equivalent to ARMv7 to ensure complete compatibility, and all privileged modes in a secure state are treated as being in EL3.

The security model of AArch32 is shown in the following diagram. In this case, EL3 is AArch32 to provide 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, it is responsible for executing the code that switches between Non-secure state and Secure state.

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

When the Normal World execution stops and the Secure World execution begins, context switching occurs between them by executing the Secure Monitor (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 the Secure World, where the principle is to redirect interrupts generated in the Secure World to EL3, regardless of the current DAIF field. However, these controls only differentiate between major interrupt types: IRQ, FIQ, and asynchronous aborts. More detailed control requires dividing interrupts into Secure and Non-secure groups. To achieve this, support from the GIC is needed, which has features to support division 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 relevant peripherals and interrupt controller registers must be marked as accessible only to secure access to prevent the Normal World from reconfiguring these interrupts.

Implementations of the security extension typically have a lightweight trusted kernel hosting security services (e.g., encryption) in the Secure World. A complete operating system runs in the Normal World and can access security services using SMC instructions. In this way, the Normal World can access service functionalities without exposing sensitive data in the code executed in the Normal World.

Security Issues in Clusters

Each core in a cluster system has the same security features. Any number of cores in the cluster can execute in the Secure World at any given point in time, and the cores can transition independently between worlds. Register controls determine 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 to a secure state.

The security system also controls the availability of debugging provisions. You can configure independent hardware debugging for Normal and Secure worlds, such as JTAG debugging and trace control, so that there is no information leakage about the trusted system. You can control hardware configuration options through a secure peripheral, or you can connect them in hardware and control them with 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. The Normal world accesses the Secure world through SMC instructions. The Secure monitor manages the switching between the Normal World and Secure World. The code of the Secure monitor is executed in a context with interrupts disabled.

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

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

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

References

security_in_an_armv8_system_100935_0100_en