In a series of texts on private computing, the article " From Privacy to Private Computing " mentions three main technical paths to achieve private computing, including: multi-party secure encryption, federated learning, and trusted execution environments. Among them, in " A Little Knowledge of Trusted Execution Environment in Privacy Computing ", there are also two mainstream implementation methods of Trusted Execution Environment (TEE), namely physical isolation TrustZone and virtualization isolation.
So, how to implement TrustZone’s trusted execution environment to support private computing?
1. About TrustZone
TrustZone technology is a system security extension technology developed by ARM. The main goal of TrustZone technology is to ensure the security of embedded systems and prevent sensitive data in the system from leaking or critical functions in the system from being attacked by malicious programs. The technical architecture of TrustZone is shown in the figure below:
TrustZone divides the resources of the entire system through a combination of software and hardware, and divides one part into a security domain and the other part into a normal domain. The security domain provides corresponding security services for the entire system, and can run only one security service or a complete operating system; the ordinary domain is a traditional general-purpose operating system. The two execution areas are independent of each other. Generally, the system running time of the two will not be affected by the other.
To ensure the independence between the security domain and the normal domain within the system, sensitive data in the security domain is managed by its internal devices. A system that supports TrustZone technology has independent address mapping tables in its security domain and common domain, making the address translation in the two execution areas completely independent, thereby eliminating the possibility of the security domain being attacked during the address translation process.
1.1 TrustZone’s CPU architecture
When implementing TrustZone technology, ARM processors are usually divided into two virtual cores, called normal mode and safe mode, which are respectively responsible for running tasks in the normal domain and the safe domain in the system.
As shown in the figure above, taking ARMv8 as an example, when the system is in a normal state, EL0 generally executes ordinary user programs; EL1 generally runs privileged software such as a general operating system kernel; EL2 is used to implement virtualization technology and generally supports virtualization. Technology related code. For system security reasons, EL3 mode does not exist in ordinary domains. When the system is in a safe state, EL0 usually runs security-related security services such as encryption and decryption; the software in EL1 is responsible for providing support for its upper-layer applications; the EL3 mode has the highest authority of the entire system, and generally runs the underlying firmware of the system, such as Security monitor for switching execution regions. In the security domain, EL2 mode usually does not exist, but after the release of ARMv8.4, developers can use it according to actual needs.
1.2 TrustZone software architecture
Applications in the security domain are mainly responsible for providing specific security services for the system, such as encryption, decryption, and safe storage of sensitive data. The trusted kernel is mainly used to support the normal operation of upper-layer applications, and is responsible for handling security interruptions in the security domain, communication with ordinary domains, and providing a unified security interface for upper-layer applications.
Applications in user space in ordinary domains are usually not aware of the existence of TrustZone, and the system will provide corresponding interfaces for these applications through user space. When communicating with each other between execution areas, message queues and other methods are usually used. The memory where these data structures are located is called shared memory. Since the software in both the security domain and the normal domain needs to operate on the data in the shared memory, and the system cannot obtain any resources in the security domain when it is in the normal state, the shared memory must be non-safe memory.
After receiving the information processed by the trusted kernel, the security service in the security domain will process the corresponding request and send the result to the corresponding shared memory, and finally return to the normal domain.
1.3 TrustZone-based TEE
Based on the technical characteristics of TrustZone, the trusted execution environment can run in the security domain of the ARM processor as an independent execution environment and provide flexible security services for the entire system. The system architecture of the TEE standard is shown in the figure below.
The trusted execution environment consists of a trusted operating system (Trusted OS, TOS) and a trusted application (Trusted Application, TA). TOS is responsible for managing the software and hardware resources within the TEE and providing TA with the resources and interfaces required for its operation. TA is responsible for providing specific security services for programs within REE. Within the TEE, TAs are also independent of each other. They cannot directly access resources in other TAs unless through special API interfaces.
2. About dual operating systems
In order to ensure the functionality and real-time requirements of the system at the same time, a dual operating system architecture can be formed by integrating real-time systems and non-real-time systems on the same hardware platform. In this architecture, the real-time system is responsible for processing real-time tasks and some safety-related tasks, and the non-real-time system is responsible for processing non-critical tasks with relatively complex functions but low real-time requirements. The performance of dual operating system architecture depends on multiple indicators such as complexity, independence, and real-time response time. These indicators are often contradictory and difficult to achieve perfection.
There are also two forms of dual operating system implementation, one is a dual-core operating system, and the other is based on virtualization technology.
2.1 Dual-core system
A dual-core system places a small real-time operating system (RTOS) kernel underneath a general-purpose operating system (GPOS) and runs GPOS as a real-time task within the system.
The dual-core system has low operating overhead and does not require any additional hardware support, but this architecture requires significant modifications to the GPOS kernel code, which significantly reduces the flexibility of the system. Moreover, the independence between RTOS and GPOS in a dual-kernel system is poor. When GPOS is attacked maliciously or its own operation errors occur, high-criticality tasks in RTOS will not be able to run normally.
2.2 Virtualized dual systems
Virtualization technology uses RTOS and GPOS to run simultaneously on the same hardware platform as two virtual machines, and the two virtual machines are managed by a virtual machine manager (Hypervisor).
Virtualization enables better independence between operating systems, and the number of operating systems is not limited to GPOS and RTOS. At the same time, all upper-layer operating systems do not need to be modified in any way, and have good flexibility. However, this technology will bring significant additional overhead to the entire system, reducing the performance of RTOS and GPOS. At the same time, the virtual machine manager must be redesigned to meet the real-time requirements of the system.
3. Dual operating systems support TrustZone
Using TrustZone technology, the embedded real-time operating system can be run in the security domain, responsible for processing high-critical real-time tasks, and the Linux kernel can be run in the common domain, responsible for processing low-critical general tasks. If the relevant tasks in the ordinary domain do not need to communicate with the security domain, the Linux kernel only needs to make minimal modifications, and will not be aware of the existence of the security domain during operation, and its internal programs will not be able to access any resources in the security domain. , ensuring the independence of the security domain. If there are programs in the ordinary domain that need to use system services provided in the security domain, you can add the TrustZone driver to the Linux kernel. The driver will be responsible for transmitting data between the security monitor and the security domain. The user layer of the ordinary domain usually also needs to add TrustZone related A library used to provide TrustZone-related API interfaces for user programs.
Among them, the security monitor is mainly responsible for executing switching between areas in the system, including:
(1) Respond to instructions from two execution areas.
(2) Responsible for responding to safety interrupts during the running of the general operating system and handing the interrupts to the interrupt handler of the real-time operating system in the safety domain for processing.
(3) When switching between execution areas occurs, it is responsible for saving and restoring relevant context and other specific switching work.
3.1 Interrupt handling mechanism
The system divides all interrupts into safe interrupts and non-safe interrupts. Non-safe interrupts are handled by Linux in the ordinary domain, and safe interrupts are handled by the RTOS in TrustZone.
If a non-safety interrupt occurs in the security domain, in order to ensure that key tasks running in the current security domain can be executed correctly, the system will temporarily ignore the interrupt. That is to say, when the RTOS is running, the IRQ interrupt will always be masked until the key tasks are completed. , the interrupt will be handled by Linux only after the system switches to the normal domain. If a security interruption occurs in the ordinary domain, in order to ensure the real-time response capability of key tasks in the security domain, the system will immediately switch to the security domain through the security monitor to handle the interruption.
3.2 Scheduling strategy
Scheduling algorithms in dual operating systems require the establishment of appropriate task models. In order to judge the schedulability of the corresponding task set in the system, it is generally necessary to calculate the worst response time of all tasks. After determining the analysis method of task response time, an algorithm is needed to assign respective priorities to all tasks in the system. After prioritization is complete, tasks in the task set are scheduled to run based on that priority sequence.
Generally, a two-level scheduling strategy can be adopted. The first level is scheduling between two operating systems, which is responsible for RTOS. It adopts a scheduling strategy that combines fixed priority and time slice rotation. In order for the scheduler in RTOS to schedule the running of Linux, there are always two region switching tasks inside RTOS. When the RTOS schedules a region switching task, it will be switched to run in Linux through the corresponding interface. Among them, one task runs as an idle task of RTOS; the other task is used to reduce the response time of the Linux kernel, improve the user experience, and reduce the impact on its performance.
4. Summary
If TEE is implemented through TrustZone technology to support private computing, then dual operating systems may be a potential solution. They also have to deal with issues such as interrupts and scheduling. Perhaps, they can be regarded as a special case of distributed operating systems.
[Related reading]