Method for constructing microkernel operating system confidential computing environment facing ARM processor
By adopting a layered system architecture on ARM processors and utilizing secure firmware, virtual machine monitors, and confidential domain management monitors, a confidential computing environment suitable for ARM microkernels is built. This solves the problem of bloated hypervisors in traditional solutions, achieves secure isolation and image verification, and enhances the flexibility and security of the system.
Patent Information
- Application Number
- CN202511708897.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-20
- Publication Date
- 2026-02-13
- Estimated Expiration
- 2045-11-20
AI Technical Summary
Existing technologies for building confidential computing environments with microkernel operating systems on ARM processors suffer from limited availability, immature software stacks and ecosystems, and the hypervisor in traditional solutions becomes bloated and difficult to adapt to ARM systems.
The system adopts a layered system architecture, including a security firmware running in EL3, a Hypervisor and a Confidential Domain Management Monitor (RMM) running in EL2, and a Host OS, a Guest OS, and a Confidential Virtual Machine (Realm VM) running in EL1 and EL0. The RMM is used to manage the confidential computing domain, avoiding the Hypervisor from undertaking specific functions and increasing system flexibility.
It provides a secure, isolated space to verify image integrity and application security, builds a confidential computing environment suitable for ARM microkernel architecture, avoids hypervisor bloat, and increases system flexibility.
Smart Images

Figure CN121145193B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to operating system environment construction technology, in particular to a microkernel operating system confidential computing environment construction technology for ARM processors. BACKGROUND
[0002] With the higher requirements for the security and reliability of embedded systems in the Internet of Things and industrial control scenarios, the security of embedded hardware architecture has attracted great attention. Among them, ARM has introduced its own security architecture and continues to update. Initially, the Trustzone of the security world was proposed in the ARMv6 architecture, supporting hardware-level address space isolation and peripheral isolation, and was widely used in mobile intelligent devices. By 2019, the S-EL2 virtualization technology for Trustzone was proposed on this basis. In 2021, the CCA confidential computing architecture was proposed on ARMv9, introducing the Realm partition supporting memory encryption and remote authentication, providing a secure and trusted isolation space for trusted virtual machines, and enhancing the security of user data on servers.
[0003] In order to improve the security and reliability of embedded systems, the architecture of the operating system has also begun to attract great attention and innovation. Under this background, the architecture of the microkernel operating system is proposed, and the kernel of the microkernel operating system only retains the simplified functions. Most of the services in the operating system are decoupled and run as independent user-mode applications in mutually isolated user-mode address spaces. This design ensures the security and fault isolation of the operating system, and developers can implement rich system services in the user mode.
[0004] Currently, only TrustZone is available on ARM to protect users' critical business and sensitive data, but it cannot be used on the server due to the difficulty of porting. The S-EL2 security virtualization architecture has the problem of immature software stack and ecology. The CCA architecture of ARMv9 has been proposed for a short time, and it will take some time to really land, so there is a slight lack of physical hardware platforms on the market. In view of these problems, Huazhong University of Science and Technology proposes an ARM container runtime environment construction method based on Android devices. The method first obtains a configuration file from the Android system or the manufacturer, modifies the compilation configuration and adds mechanisms, and compiles the customized kernel according to the modified file. Then, the image that can run on Android is customized, and the container management mechanism is implemented, so as to achieve the purpose of building an ARM runtime environment. Shanghai Jiaotong University proposes a confidential computing environment construction method and system based on ARM architecture. In this scheme, the virtual machine monitor plays a major role, realizes the creation and destruction of Realm, loads the security image into Realm, verifies the security of the image, encrypts the Realm memory according to the percentage configured by the user for the application, and achieves the purpose of low-cost physical resource isolation. South Lake Laboratory also proposes a high-throughput confidential computing method and system based on RISC-V architecture. This system includes a security manager in machine mode and a security domain that runs a secure kernel and an application.
[0005] The traditional ARM security architecture has the defects of limited available range, immature software stack and ecology, etc. Among various solutions, Huazhong University of Science and Technology proposes a construction method to build a container running ARM environment, but this scheme is for the Android macro kernel system, and some mechanisms reflected in the configuration file may not be implemented in the micro kernel. In addition, the program is not verified for security when loaded into the container, and there is no isolation mechanism to ensure the security of the program. The scheme of Shanghai Jiaotong University completely realizes resource isolation, Realm management and security verification, but in this scheme, the virtual machine monitor Hypervisor needs to implement multiple mechanisms including Realm creation, security verification and memory encryption, which will make the Hypervisor bloated and not in line with the design idea of micro kernel. In the scheme, the key for security verification must be stored in the Trustzone, which will bring inconvenience to platforms that do not support Trustzone. The scheme of South Lake Laboratory also establishes a relatively complete system including a security manager, a security domain and a verification mechanism, but this scheme is implemented based on the RISC-V architecture system, which is difficult to directly migrate to the ARM system for use. SUMMARY
[0006] The technical problem to be solved by the present application is to provide a method for dynamically constructing a confidential computing environment at runtime in view of the requirement for kernel size in a microkernel operating system.
[0007] The technical scheme adopted by the present application to solve the above technical problems is a microkernel operating system confidential computing environment construction method for an ARM processor, wherein the confidential computing environment is realized based on a layered system architecture, and the architecture comprises:
[0008] A secure firmware running at ARM exception level EL3, used to provide underlying security services;
[0009] A virtual machine monitor Hypervisor and a confidential domain management monitor RMM running at ARM exception level EL2, wherein the Hypervisor and the RMM run in mutually isolated address spaces; the Hypervisor is responsible for virtualization management and resource scheduling strategies; the RMM, as an independent module, is responsible for implementing specific management mechanisms of the confidential computing domain;
[0010] Three parallel and isolated execution environments running at ARM exception levels EL1 and EL0: a host operating system Host OS, a guest operating system Guest OS and a confidential virtual machine Realm VM;
[0011] The method comprises the following steps:
[0012] In the microkernel operating system startup process, the RMM is dynamically loaded as an independent module to the running environment of EL2 through a secure startup process;
[0013] At runtime, the confidential virtual machine Realm VM is created and managed through the communication and cooperation between the Hypervisor and the RMM, so as to provide a confidential computing environment.
[0014] In the microkernel operating system architecture of the present application, the virtualization management program Hypervisor does not implement specific functions and mechanisms of confidential computing, but places this part of content in the operating system kernel RMM for the virtual machine to implement, the Hypervisor provides a module and an interface for communication with the RMM, and the RMM is loaded at startup. In this way, the Hypervisor or the kernel is prevented from becoming bloated, and in addition, whether the RMM is loaded at startup is optional, thereby increasing the flexibility of the system.
[0015] The present application has the beneficial effects that it is suitable for a confidential computing environment based on an ARM microkernel architecture, supports a confidential computing domain, can provide a secure isolated space, and can verify the integrity of an image and the security of an application. The construction method increases the flexibility of the system, and at the same time, prevents the virtual machine monitor module from becoming bloated. BRIEF DESCRIPTION OF DRAWINGS
[0016] Figure 1This is a diagram of the architecture of an ARM confidential computing environment based on a microkernel architecture. Detailed Implementation
[0017] Under the ARM architecture, this invention utilizes, as Figure 1 The microkernel-based ARM confidential computing environment architecture shown decouples the ordinary virtualization environment from the confidential computing environment through exception level layering and component isolation, providing an end-to-end secure execution environment for sensitive applications.
[0018] The following description is based on two dimensions: ARM Exception Level (EL) and components in different execution environments.
[0019] 1. ARM Exception Level (EL) Hierarchical Logic:
[0020] ARM processors implement access control through exception levels EL0 to EL3, with higher EL numbers indicating higher privileges.
[0021] EL3, the highest privilege level: runs secure firmware and is responsible for underlying secure boot, permission management, and initialization of the secure environment.
[0022] Virtualization level EL2: Runs the Hypervisor and system kernel (the kernel of the Host OS), as well as the Realm Management Monitor (RMM) in confidential computing, which is responsible for managing the isolation of virtual machines and confidential domains.
[0023] Operating system kernel level EL1: Runs system services, namely the kernel services of the Host OS, the Guest kernel for the operating system kernel used by virtual machines, and the security kernel of the confidential domain that provides underlying security support for confidential applications.
[0024] User application level EL0: Runs ordinary applications, such as user programs in the Host OS and Guest OS, and confidential applications, such as sensitive programs that require strong isolation protection and run in the Realm VM.
[0025] 2. Components and isolation logic of each execution environment
[0026] It consists of three parallel execution environments: the Host OS, the Guest OS (i.e., ordinary virtual machines), and the Realm VM (a confidential virtual machine used for confidential computing). These are isolated through ARM's permission levels, virtualization mechanisms, and security mechanisms.
[0027] 2.1 Host Operating System
[0028] EL0: Run normal user applications, no special privileges, is the user interaction program layer.
[0029] EL1: Run system services, manage the hardware and resources of the host system. System services such as device drivers, process management, etc. Kernel-level functions.
[0030] EL2: Run the kernel of the Host OS and the Hypervisor. The kernel of the Host OS is responsible for system bottom scheduling. The Hypervisor is responsible for virtualization, managing resource allocation and isolation of the Guest OS.
[0031] 2.2 Customer Operating System Guest OS
[0032] EL0: Run user applications within the virtual machine, completely isolated from the applications of the Host OS.
[0033] EL1: Run the Guest kernel, responsible for resource management within the virtual machine. The Guest kernel is the operating system kernel of the virtual machine itself, such as the Linux kernel.
[0034] EL2: Managed by the Hypervisor, the operation of the Guest OS is constrained by the Hypervisor, achieving virtualization isolation with the Host OS.
[0035] 2.3 Confidential Virtual Machine Realm VM
[0036] EL0: Run confidential applications, which need to be protected from being snooped or tampered with by the Host / Guest OS. Run confidential applications such as encryption algorithms, privacy computing programs, and other sensitive loads.
[0037] EL1: Run the security kernel. The security kernel provides minimal and secure kernel services for confidential applications, such as memory isolation and process scheduling.
[0038] EL2: Run RMM. RMM is the exclusive manager of the confidential domain, responsible for the creation, destruction, and security isolation of the Realm VM, cooperating with the Hypervisor but maintaining the independence of the confidential domain.
[0039] 3. Core design of confidential computing The invention builds a confidential computing environment through the multi-level permissions and component isolation of ARM:
[0040] Confidential applications run in EL0 of the Realm VM, and their security kernels run in EL1, managed exclusively by RMM in EL2, and secured by the security firmware in EL3 for the most basic security startup and permission control.
[0041] This hierarchical design ensures that confidential applications are completely isolated from the common Host / Guest OS, even if the Hypervisor is attacked, the confidential data and code of the Realm VM are protected by the hardware-level permission mechanism, thus achieving the core goal of confidential computing, that is, securely executing sensitive computing tasks on untrusted infrastructure.
[0042] The present application differentiates and disassembles the Host OS, Guest OS, and Realm VM three execution environments in the four-level permissions of ARM. This multi-environment, fine-grained permission-component mapping is suitable for the special architecture expression of ARM-based microkernel confidential computing.
[0043] The bottom layer EL3 firmware, also known as exception level 3 firmware or secure monitor level firmware, is a special bottom layer firmware. Compared with the bottom layer firmware before the processor architecture version ARMv6, it provides some special services in addition to the regular driver functions such as CPU, memory, flash, serial port, etc. hardware initialization and access, such as secure boot, power state coordination interface PSCI, secure monitor call SMC command processing, memory security, authentication service, integrity measurement, etc. and provides an interface for the services of the upper layer. Among them, secure boot is one of the important functions, which divides the startup process into BL1, BL2, BL31, BL32, and BL33 five files, and loads them in stages, that is, BL1 loads BL2, BL2 loads BL31, BL32, and BL33. BL2 loads the RMM image, and BL33 is generally a universal bootloader uboot. Another important function is SMC processing. SMC is an important command for interaction between Hypervisor and RMM.
[0044] The kernel of the microkernel operating system runs at EL2, and the kernel only contains basic services, including thread management, IPC, interrupt management, and the like. Other more functions are placed in the system services in the user state to provide a running environment for application programs. In order to support virtualization, the kernel of EL2 also adds virtualization extensions, including processor virtualization, memory virtualization, interrupt virtualization, and the like. In order to build a confidential computing environment, EL2 also runs an RMM module. The RMM provides management and services for virtual machines in the confidential computing domain, such as deciding the timing of destroying a Realm, adding or reducing memory for a Realm, and safe services such as verifying whether a host in a Realm is correct and whether code is safe, and mutual isolation between Realms. On the other hand, the RMM only provides mechanisms, but specific strategies are provided by the Hypervisor, so some mechanisms are needed to implement communication between the RMM and the Hypervisor and control of the RMM by the Hypervisor, which is specifically implemented through SMC commands and a Realm management interface RMI. First, the Hypervisor calls an interface function, and the interface function executes an SMC instruction. When the instruction is executed, the ID of the corresponding service on the RMM and other calling parameters are passed. Execution of the SMC causes the system to trap into EL3, triggers an SMC interrupt, and the program enters the SMC processing program, executes the relevant RMM service according to the parameters passed by the Hypervisor, and returns to the upper layer when the execution is completed or the strategy provided by the Hypervisor needs to be called.
[0045] The core of building a confidential computing environment is to load an RMM image module, build a confidential computing domain, execute a trusted program in the confidential computing domain, call a safe service, and destroy the confidential computing domain after the trusted program is completely executed. The execution steps of the module construction are as follows:
[0046] When the microkernel operating system starts, a secure boot mechanism is executed, and the original direct boot through uboot is changed to sequentially start BL1, BL2, and BL3X. (BL33 is the original uboot) BL1 verifies and loads BL2 when executed, and BL2 also performs similar operations. At the same time, BL2 loads RMM to prepare for subsequent work. The RMM runs as an independent thread in a mutually isolated address space.
[0047] When a user wants to run trusted code in a secure, isolated space, a confidential computing enclave can be created through some interfaces to execute the trusted code. First, a confidential computing enclave is created at EL2, which runs a secure virtual machine that can perform sensitive operations such as encryption and decryption algorithms, fingerprint and face recognition, etc. This process can be completed through Hypervisor. After the confidential computing enclave is created, a secure image can be loaded into the enclave. After loading, the security of the image and program needs to be proved by certain means. For the image, not only the image is built, but also each layer of the image is hashed and signed separately. At the same time, rich metadata Metadata is attached to the image, and the metadata itself is also signed. These metadata can include a list of dependencies and their versions, security scanning reports, etc. When the confidential computing virtual machine starts, in addition to loading the image, a lightweight, trusted verifier program is also loaded. The task of this verifier is not to directly calculate the hash of the entire image, but to:
[0048] a. Get the signed build metadata and layer-by-layer signature associated with the image from the image repository or blockchain.
[0049] b. Verify the validity of these signatures layer by layer, such as verifying whether the signature key comes from a trusted builder.
[0050] c. According to the needs, verify whether the policy in the metadata meets the requirements, for example: "all high-risk CVEs have been fixed".
[0051] When the client is authenticated, the verifier can generate a report signed by the hardware key of the TEE, providing the client with double assurance: the hardware environment is trusted + the image content is trusted. For the application, the RMM can be made to maintain a lightweight, formally verified monitor. This monitor runs with very high privileges, and can even monitor the behavior of the main application, defining a set of critical runtime behavior policies for the application, such as control flow integrity (CFI), system call whitelists. The monitor continuously checks the behavior of the application. When the remote verifier requests, it can generate a proof endorsed by the TEE, stating that "the application's behavior has not deviated from the established policies over a period of time". When these two steps are successfully completed, the relevant programs and code need to be run. Each time a program is run, the software correctness and security in the confidential computing domain need to be proven, and the memory in the secure domain is encrypted when the program is running. Each chip or each domain has a key for encrypting memory, which is generated or derived when the secure domain is created, and is erased from the memory when it is destroyed. The encryption engine is integrated in the memory controller of the CPU, or between the CPU core and the last level cache (LLC). This is the physical location where encryption / decryption occurs. The encryption algorithm usually uses a lightweight, low-latency symmetric encryption algorithm such as AES. In order to further reduce the delay, the AES-XTS mode or similar adjustment mode is usually used. One of the most critical strategies for encryption is address-dependent encryption. The purpose is to prevent data replay attacks. The encryption engine not only uses a domain-specific key, but also uses the memory address being accessed as an input to the encryption algorithm. The memory can be encrypted at a certain proportion according to the configuration provided by the user when encryption. The service of running a trusted program is provided by the RMM to the upper layer application through the Realm Service Interface (RSI), but the underlying is implemented by calling the code in the Hypervisor through the RMI.
[0052] The method for building an ARM confidential computing environment can load the RMM image module when starting the operating system, create a confidential computing domain and run a trusted application at runtime, perform various security services, and destroy the confidential computing domain after the application is run. At the same time, the RMM can be loaded in the form of an image file in the BL2 stage of secure boot, and the RMM is dynamically loaded by the operating system and runs as an independent thread in an address space isolated from the Hypervisor, and communicates with the Hypervisor through SMC interrupts and RMI.
[0053] In effect, the application solves the shortcomings of the method for building an ARM running container environment of Android. The method for building an ARM running container environment of Android only provides a running environment for programs based on ARM architecture, and this running environment is not a secure and isolated environment, and address isolation is not achieved, and the security of the application is not verified. While the application supports confidential computing domain, achieves the purpose of providing a secure and isolated space, and can verify the integrity of the image and the security of the application. At the same time, the application solves the shortcomings of the traditional confidential computing environment building process. When building the traditional confidential computing environment, all confidential computing environment management functions are placed in the virtual machine manager, resulting in the problem of kernel and Hypervisor bloating. The scheme places the mechanism of confidential computing environment management in RMM, and Hypervisor is only responsible for strategy. That is, the function modules and specific mechanisms of confidential computing, such as address isolation, memory particle protection, remote authentication, information encryption, key management, etc., are not directly implemented in Hypervisor. Instead, the confidential computing service is implemented in the confidential computing domain management monitor. Hypervisor retains the interface for communication with RMM, and RMM and Hypervisor communicate with each other. RMM is loaded at startup or runtime, and is not a resident kernel, which makes the size of Hypervisor smaller and more flexible.
Claims
1. A method for constructing a confidential computing environment for a microkernel operating system targeting ARM processors, characterized in that, The confidential computing environment is implemented based on a layered system architecture, which includes: Security firmware running at ARM exception level EL3 is used to provide underlying security services; The Hypervisor and the Confidential Domain Management Monitor (RMM) run at ARM exception level EL2. The Hypervisor and RMM run in isolated address spaces. The Hypervisor is responsible for virtualization management and resource scheduling strategies. The RMM, as an independent module, is responsible for implementing the specific management mechanism of the confidential computing domain. Three parallel and isolated execution environments run at ARM exception levels EL1 and EL0: the Host OS, the Guest OS, and the Realm VM. The method includes the following steps: During the startup process of the microkernel operating system, the RMM is dynamically loaded as an independent module into the EL2 runtime environment through a secure boot process; During runtime, the Hypervisor and RMM communicate and collaborate to create and manage the confidential virtual machine Realm VM to provide a confidential computing environment.
2. The method for constructing a confidential computing environment for a microkernel operating system for ARM processors as described in claim 1, characterized in that, The secure boot process includes loading and verifying BL1, BL2, BL31, BL32 and BL33 in sequence, with the RMM image file being loaded in the BL2 stage.
3. The method for constructing a confidential computing environment for a microkernel operating system for ARM processors as described in claim 1, characterized in that, The Hypervisor and RMM communicate through the security monitor calling SMC commands and the Realm management interface RMI.
4. The method for constructing a confidential computing environment for a microkernel operating system for ARM processors as described in claim 1, characterized in that, After creating the confidential virtual machine Realm VM, the following steps are also included: Load the security image into the confidential virtual machine and perform integrity verification on the security image; the verification includes performing hash and signature verification on the image layer by layer, and verifying whether the attached signed metadata complies with the security policy.
5. The method for constructing a confidential computing environment for a microkernel operating system for ARM processors as described in claim 1 or 4, characterized in that, When an application runs in a confidential Realm VM, a monitor maintained by the RMM monitors the application's behavior to ensure it complies with predefined security policies.
6. The method for constructing a confidential computing environment for a microkernel operating system for ARM processors as described in claim 1, characterized in that, During the operation of the confidential virtual machine Realm VM, address-related encryption is performed on the memory allocated to it.
7. The method for constructing a confidential computing environment for a microkernel operating system for ARM processors as described in claim 1, characterized in that, RMM provides security services to applications running in the confidential virtual machine through the Realm service interface.
Citation Information
Patent Citations
Method and device for executing GPU (Graphics Processing Unit) task in confidential computing architecture
CN117807587A
ARM (Advanced RISC Machines) TrustZone architecture for realizing secure world Jailhouse virtualization
CN119201351A