A method of loading a trusted execution environment using a jailhouse

Abstract

The application provides a method for loading a trusted execution environment using jailhouse, selecting a memory region with continuous physical addresses from the address space of Linux; using jailhouse to identify the current hardware architecture and enter the virtualization highest privilege level of the current hardware architecture, isolating the memory region from the address space of Linux and configuring the memory region as a secure unit; obtaining a secure unit description file, mapping logical resources in the description file to physical resources according to an architecture adaptation rule, and loading a TEEOS kernel into the secure unit; after the TEEOS is started, establishing a standardized data exchange channel between Linux and the TEEOS by using virtual shared memory, and intercepting and processing illegal access by a two-stage address conversion, IOMMU / interrupt routing and exception trapping mechanism. The application can realize the unified deployment of a TEEOS across platforms without relying on a specific hardware security world.

Description

Technical Field

[0001] This invention relates to virtualization technology, and more specifically to a method for loading a trusted execution environment using jailhouse. Background Technology

[0002] With the rapid development of the Internet of Things, edge computing, and domestically produced computing power, Trusted Execution Environments (TEEs) have become a core technology for protecting sensitive data (such as keys, biometrics, and AI models). However, traditional TEE implementations (such as those based on ARMTrustZone) have the following limitations: 1. Severe architecture binding: TEEs often rely heavily on specific hardware security states (such as ARM's SecureWorld), making it difficult to smoothly migrate the same set of security business logic to x86, LoongArch and RISC-V platforms.

[0003] 2. Resource constraints: The hardware-level Secure RAM has a very small capacity, making it difficult to support large-scale encrypted data or high-performance secure computing.

[0004] 3. High development barriers: The secure boot chains and firmware interfaces of different architectures vary greatly, which increases the complexity of system integration. Summary of the Invention

[0005] The technical problem to be solved by this invention: 1. Hardware-level "islands": The security state switching mechanisms of different instruction set architectures (ISAs) are incompatible, which makes it impossible for the TEEOS image to run across platforms.

[0006] 2. Risks of complex TCBs: Traditional virtual machines (such as KVM) have a large amount of code, and their Trusted Foundation (TCB) is too bloated and easily attacked, which does not meet the security definition of TEE.

[0007] 3. Lack of ecosystem for RISC-V and domestic architectures: The emerging RISC-V architecture has not yet achieved complete standardization in hardware-level isolation, and there is an urgent need for a general secure boot solution based on standard virtualization extension (H-extension).

[0008] To address the aforementioned issues in existing technologies, a method is provided that uses jailhouse to load a trusted execution environment, enabling a unified deployment of a single TEEOS across architectures (ARM / x86 / Loongson / RISC-V).

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for loading a trusted execution environment using jailhouse includes the following steps: Select a physically contiguous memory region from the Linux address space; The jailhouse is used to identify the current hardware architecture and enter the highest privilege level of the current hardware architecture to isolate the memory region from the Linux address space and intercept access requests to the memory region. Obtain the description file of the security cell and use jailhouse to remove the resources allocated to TEEOS from the Linux visible resource set according to the description file, and configure the security cell Inmate Cell containing the memory region and the resources allocated to TEEOS; The TEEOS kernel is loaded into the security unit Inmate Cell, and the jailhouse is used to jump the CPU cores in the resources allocated to TEEOS to the TEEOS entry address according to the reset instruction or context switch instruction of the current hardware architecture. After TEEOS starts, it uses virtual shared memory technology to establish a data exchange channel between Linux and TEEOS, and uses jailhouse to intercept and handle unauthorized access attempts.

[0010] Furthermore, when selecting a physically contiguous memory region from the Linux address space, this is specifically done through the memory mapping parameter memmap or the reserved-memory node in the Device Tree, to delineate a physically contiguous memory region from the Linux address space. When using jailhouse to identify the current hardware architecture and enter the highest privilege level of the current hardware architecture to isolate the memory region from the Linux address space, this specifically involves entering the highest privilege level of the current hardware architecture to take over the exception vector table, the Memory Management Unit (MMU), and interrupt control-related configurations, and completely erasing the memory region from the Linux address space. This restricts the running Linux to the Root Cell and prevents it from reading or modifying the memory region. The Root Cell is the region in the Linux address space other than the memory region.

[0011] Furthermore, the highest privilege levels in the current hardware architecture include: If the current hardware architecture is ARMv8 / v9, then the highest privilege level is EL2 privilege level; If the current hardware architecture is x86, then the highest privilege level is VT-x Root mode; If the current hardware architecture is RISC-V, then the highest privilege level is HS mode; If the current hardware architecture is LoongArch, then the highest privilege level is VZ mode.

[0012] Furthermore, the description file of the security unit adopts a cross-architecture unified field format, including at least a file header field, a CPU set field, a memory region field, an I / O region field, an interrupt routing field, a communication region field, and a security policy field; wherein, the CPU set field describes the processor resource to be allocated using a logical CPU identifier, and is mapped to the MPIDR / Core ID under the ARM architecture, the APIC ID under the x86 architecture, the Hart ID under the RISC-V architecture, or the CPU ID under the LoongArch architecture through the architecture mapping subfield; the I / O region field describes the peripheral resource using the physical base address, address length, access permissions, DMA isolation domain, and interrupt number.

[0013] Furthermore, when using jailhouse to remove resources allocated to TEEOS from the Linux visible resource set according to the description file, the process includes: freezing ordinary tasks on the target CPU core, migrating or disabling interrupts bound to the target CPU core, placing the target CPU core in a Hypervisor-controlled halted state; deleting the target memory block from the two-stage address translation table of the Root Cell and refreshing the translation backup buffer and necessary cache states; and switching the interrupt routing and DMA access domain of the target peripheral from the ordinary unit Root Cell to the secure unit Inmate Cell, thereby completing the hardware resource removal during the main operating system's operation without requiring a reboot.

[0014] Furthermore, configuring the InmateCell, a secure unit containing the memory region and the resources allocated to TEEOS, includes: if the current hardware architecture is RISC-V, then the physical Hart is hard-splitted to TEEOS through HS mode, the hstatus, hedeleg, hideleg and virtual interrupt control states corresponding to the Hart are set, and hgatp is set to point to the G-stage page table of the secure unit, so that TEEOS is started as a VS mode kernel, and its memory access address is translated to the real physical address through VS stage address translation and then through G-stage address translation.

[0015] Furthermore, configuring the InmateCell security unit, which includes the memory region and the resources allocated to TEEOS, also includes an I / O tunneling step, specifically including: The mapping of peripheral memory mapping input / output addresses to the Inmate Cell address space is established based on the I / O region field and the interrupt routing field; For peripherals with direct memory access capabilities, configure an input / output memory management unit or a system memory management unit so that the peripheral can only access the private memory of the security unit or the authorized shared memory.

[0016] Furthermore, after loading the TEEOS kernel into the secure unit Inmate Cell, and before TEEOS starts, the process also includes: Perform an integrity check on the memory containing the TEEOS image; A minimum boot context is established for the target CPU core. The minimum boot context includes at least the entry address, stack pointer, boot parameter address, exception vector entry, initial page table base address, and interrupt masking state.

[0017] Furthermore, when using jailhouse to intercept and handle unauthorized access attempts, it includes: intercepting root cell access to the private memory of the security unit through a two-stage address translation table; intercepting unauthorized peripheral access through memory-mapped I / O traps or I / O port traps; intercepting unauthorized direct memory access through the IOMMU or SMMU; and intercepting unauthorized interrupt injection through the interrupt controller routing table. When an unauthorized access occurs, jailhouse performs at least one of the following actions: denying access, logging the source of access, injecting an exception, resetting the corresponding security unit, or disabling the corresponding peripheral.

[0018] Furthermore, when establishing a data exchange channel between Linux and TEEOS using virtual shared memory technology, a segment of shared memory is simultaneously mapped to both the ordinary unit Root Cell and the secure unit Inmate Cell. A control area, a request circular queue, a response circular queue, and a data buffer are then partitioned within the shared memory. The ordinary unit Root Cell and the secure unit Inmate Cell send requests and responses through the ivshmem doorbell interrupt or equivalent event notification mechanism, and data visibility is ensured through memory barriers, cache refresh, or cache consistency attributes.

[0019] Compared with the prior art, the advantages of the present invention are as follows: This invention introduces a lightweight partition management program to construct a logically isolated secure space, Inmate Cell, in the "Normal World" through software definition, enabling a single TEEOS system to be deployed uniformly across architectures (ARM / x86 / Loongson / RISC-V). Attached Figure Description

[0020] Figure 1 This is a flowchart of the method of the present invention.

[0021] Figure 2This is an architectural diagram of the method of the present invention. Detailed Implementation

[0022] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0023] This embodiment describes a method for loading a trusted execution environment using jailhouse, based on a general architecture of the jailhouse static partition management program. Jailhouse does not participate in task scheduling, and its code is extremely concise. By activating the isolation layer at the highest virtualization privilege level of each architecture (such as ARM EL2, x86 VT-x Root Mode, RISC-V HS-mode, Loongson VZ), the physical hardware is hard-divided into Root Cell (normal unit) and Inmate Cell (secure unit), enabling the booting of TEEOS within NormalWorld with architecture independence.

[0024] Implementing this method requires leveraging the virtualization extension features of each processor architecture: ARMv8 / v9: Capture sensitive instructions using the EL2 privilege level.

[0025] x86: Root mode isolation is achieved using VT-x (VMX) technology.

[0026] RISC-V: Utilizes H-extension (Hypervisor extension). In this mode, the processor has an HS (Hypervisor-ext Supervisor) mode, which can manage and isolate the underlying VS (Virtual Supervisor) mode.

[0027] LoongArch: Extends the instruction set using VZ virtualization.

[0028] like Figure 1 and Figure 2 As shown, the method in this embodiment includes the following steps: Step 1: Cross-architecture physical memory reservation, specifically selecting a contiguous memory region from the Linux address space.

[0029] like Figure 1 As shown, in the early stages of Linux booting, a contiguous memory region is allocated from the Linux address space using common architectural memory mapping parameters (memmap or the reserved-memory node in the Device Tree). This region will be completely erased from the Linux address space in subsequent steps.

[0030] Step 2: Activate the jailhouse hardware isolation layer. Specifically, jailhouse is used to identify the current hardware architecture and enter the highest privilege level of the current hardware architecture to isolate the memory region from the Linux address space and intercept access requests to the memory region.

[0031] like Figure 1 As shown, after identifying the current hardware architecture, the jailhouse driver enters the highest privilege level of the hardware, taking over the exception vector table, memory management unit (MMU), and interrupt control-related configurations. This restricts the running Linux system to the Root Cell, preventing it from reading or modifying the memory region. In this embodiment, the Root Cell is a region in the Linux address space other than the memory region, thus activating the isolation layer. The specific implementation steps are as follows: 1. Environment Scan: The jailhouse driver identifies the current hardware architecture (identifying whether it is RISC-VHS mode or ARM EL2, etc.).

[0032] 2. Takeover of Privilege Level: The jailhouse enters the highest privilege level of the hardware, taking over control of the exception vector table, memory management unit (MMU), and interrupt control-related configurations. Specifically, if the current hardware architecture is ARMv8 / v9, the highest privilege level is EL2; if the current hardware architecture is x86, the highest privilege level is VT-x Root mode; if the current hardware architecture is RISC-V, the highest privilege level is HS mode; and if the current hardware architecture is LoongArch, the highest privilege level is VZ mode.

[0033] 3. Resource reallocation: At this point, the running Linux is confined to the root cell. The jailhouse intercepts Linux's access requests to the memory reserved in step 1, ensuring that it cannot read or modify that area.

[0034] Step 3: Configure the Inmate Cell. Specifically, obtain the description file of the Inmate Cell and use jailhouse to remove the resources allocated to TEEOS from the Linux visible resource set according to the description file, and configure the Inmate Cell containing the memory region and the resources allocated to TEEOS.

[0035] like Figure 1As shown, after the isolation layer is activated, a description file (.cell) is loaded, which defines cross-architecture abstract resources. This description file does not directly specify the register names of a particular processor vendor; instead, it uses a format of "unified resource fields + architecture mapping fields," allowing the same build process to generate corresponding InmateCell configurations on different hardware architectures. By loading and parsing the description file to define cross-architecture abstract resources, a resource description foundation is provided for the subsequent construction of security units.

[0036] In this embodiment, the description file of the security unit Inmate Cell includes at least the following data structures: a file header, basic cell information, a CPU set (cpu_set), memory regions (memory_regions), I / O regions (io_regions), interrupt routes (irq_routes), communication regions (comm_regions), and a security policy (security_policy). The file header includes the fields magic, version, arch, cell_id, and checksum; the basic cell information includes the fields name, entry_addr, image_load_addr, boot_args, and privilege_mode; the security_policy is used to declare the default denial policy, the allowed shared memory range, the allowed peripheral range, and the actions to handle unauthorized access.

[0037] The field naming rules are as follows: Fields are uniformly named using lowercase letters and underscores, representing logical meanings independent of the architecture; architecture-related fields are uniformly placed in the `arch_map` substructure, and the field value records the physical identifier of the logical resource under the target architecture. For example, in `cpu_set`, `logical_cpu_id` represents the logical CPU number, `arch_map.arm_mpidr` represents the ARM MPIDR affinity value, `arch_map.x86_apic_id` represents the x86 APIC ID, `arch_map.riscv_hart_id` represents the RISC-V Hart ID, and `arch_map.loongarch_cpu_id` represents the LoongArch CPU number.

[0038] Each entry in `memory_regions` includes fields for `region_id`, `owner`, `phys_start`, `virt_start`, `size`, `attr`, and `shareable`. `owner` can be `root`, `inmate`, or `shared`, and `attr` describes read, write, execute, cache attributes, and device memory attributes. Each entry in `io_regions` includes fields for `device_id`, `bus_type`, `phys_start`, `size`, `access`, `irq_refs`, and `dma_domain`, used to describe MMIO, PIO, PCIe BAR, or on-chip peripheral address ranges. Each entry in `irq_routes` includes fields for `irq_id`, `source_device`, `target_cell`, `target_cpu`, and `trigger_type`, used to uniformly describe ARM GIC SPI / PPI, x86 IOAPIC / MSI, RISC-V PLIC interrupt, or LoongArch interrupt controller routes.

[0039] After loading the unified security element description file, which contains fields for CPU sets, memory regions, I / O regions, interrupt routes, communication regions, and security policies, the jailhouse first performs overlap detection, permission validity detection, and resource ownership detection. Then, the architecture adaptation layer converts the unified resource object into page table entries, interrupt controller configurations, and peripheral access permission configurations for the corresponding architecture. Based on the architecture adaptation rules, the logical resources in the description file are mapped to physical resources such as ARM Cores, x86 APIC IDs, RISC-V Hart, or LoongArch CPUs. Because the upper-level fields of the description file remain consistent, there is no need to change the communication protocol and resource allocation logic on the TEEOS side when generating the security element; only the physical identifiers in the `arch_map` need to be replaced to complete cross-architecture deployment.

[0040] like Figure 1 As shown, after loading the description file, jailhouse removes the resources allocated to TEEOS from the Linux visible resource set according to the description file, and configures the Inmate Cell, a security unit containing the memory region and the resources allocated to TEEOS; the above resource removal occurs during the main operating system's runtime and does not require a reboot. The specific process includes: Dynamic resource removal: In the Root Cell configuration, jailhouse removes CPU cores, memory blocks, interrupt numbers, and peripherals intended for allocation to TEEOS from the Linux visible resource set. For CPU cores, it first freezes ordinary tasks through Linux CPU hot-plugging, CPU isolation, or scheduling affinity control, then migrates timer interrupts, peripheral interrupts, and soft interrupts, and finally, jailhouse sends an IPI or architecture equivalent event to put the target CPU into a Hypervisor stall state. For memory blocks, jailhouse deletes the physical range mapping in the Root Cell's two-stage address translation table and refreshes the TLB and necessary cache states. For peripherals, jailhouse disables MMIO mapping on the Root Cell side, migrates interrupt affinity, and binds the peripheral's DMA access domain to the secure cell.

[0041] No reboot switching: The removal of CPU, memory and I / O resources mentioned above occurs during the operation of the main operating system. The jailhouse only modifies the resource ownership table and the two-stage address translation table of the Hypervisor layer, without requiring a Linux reboot. If it is detected that there are still unmigratable tasks on the target CPU, the target interrupt cannot be migrated, or the target memory is still occupied by the RootCell, the creation of the safe cell will be refused and an error will be returned to avoid resource overlap.

[0042] Therefore, removing resources allocated to TEEOS from the Linux visible resource set includes: freezing ordinary tasks on the target CPU core, migrating or disabling interrupts bound to the target CPU core, placing the target CPU core in a Hypervisor-controlled halted state; deleting the target memory block from the two-stage address translation table of the Root Cell and refreshing the translation backup buffer (TLB) and necessary cache states; and switching the interrupt routing and DMA access domain of the target peripheral from the ordinary world Root Cell to the secure unit Inmate Cell, thereby completing the hardware resource removal during the main operating system's operation without requiring a reboot.

[0043] When configuring the Inmate Cell, a security unit containing the memory region and resources allocated to TEEOS, the following is included: CPU Assignment: For example, assign RISC-V Hart 2 and Hart 3 to TEEOS, and assign ARM Core 3 to TEEOS. CPU assignment uses a mutual exclusion set method, and the CPU sets of the Root Cell and Inmate Cell must not overlap; the jailhouse does not perform time-slice scheduling on the same physical CPU, but instead hard-slices the target CPU to a safe unit, allowing TEEOS to run exclusively.

[0044] In the ARM architecture, CPU assignment determines the target core based on the MPIDR affinity value and configures the EL2 context, GICCPU Interface, and virtual interrupt routing. In the x86 architecture, the target logical processor is determined based on the APIC ID, and VMCS, EPT, and interrupt delivery vectors are configured. In the RISC-V architecture, the target physical Hart is determined based on the Hart ID, the jailhouse runs in HS mode, and an independent VS mode context is established for this Hart. In the LoongArch architecture, an independent running context is configured based on the CPU number and VZ virtualization extension.

[0045] For the RISC-V architecture, jailhouse allocates an independent HART set for TEEOS in HS mode, sets the corresponding hstatus, hedeleg, hideleg, and virtual interrupt control status for that HART, and sets hgatp to point to the G-stage page table of the secure cell. TEEOS boots as a VS-mode kernel; its memory access addresses are first translated by the VS stage, and then by the G-stage address translation to the actual physical address. The G-stage page table only maps TEEOS private memory, the authorized peripheral MMIO area, and the ivshmem shared area, not the Root Cell private memory. The Root Cell's G-stage page table also does not map TEEOS private memory; therefore, even with software defects, neither can access the other's private areas by modifying ordinary page tables.

[0046] I / O tunneling: Directly assigns the physical address of hardware peripherals requiring encryption (such as encryption engines and secure UARTs) to the Inmate Cell. During I / O tunneling, the io_regions and irq_routes in the description file jointly determine the peripheral's MMIO address, access permissions, interrupt number, target CPU, and DMA access domain.

[0047] The jailhouse generates a memory map of devices accessible to the security unit based on io_regions and removes identical physical address ranges from the Root Cell's MMIO mapping. For peripherals with DMA capabilities, it further configures the IOMMU / SMMU or platform-equivalent DMA isolation unit, ensuring that the peripheral can only access the security unit's private memory or authorized shared memory, and cannot access the Root Cell's memory. For peripherals that do not require exclusive TEE access, only the read-only status register or shared notification register is enabled, and writing to the control register is prohibited, thereby preventing the Root Cell and the security unit from competing for device state.

[0048] Step 4: TEEOS image booting and context initialization. Specifically, the TEEOS kernel is loaded into the security unit Inmate Cell, and the jailhouse is used to jump the CPU cores in the resources allocated to TEEOS to the TEEOS entry address according to the reset instruction or context switching instruction of the current hardware architecture.

[0049] like Figure 1 As shown, after the hardware resources are dynamically stripped, the TEEOS kernel is loaded into the Inmate Cell. The jailhouse, based on the current hardware architecture's reset or context switch instructions, forces the CPU core allocated to TEEOS to the TEEOS entry address, completing the Inmate Cell's startup. The specific process is as follows: 1. Image Injection: Loads the TEEOS kernel, compiled for the current architecture, into the reserved memory.

[0050] 2. Forced jump: jailhouse forces a jump to the TEEOS entry address of a specified CPU core through architecture-related reset instructions or context switching instructions (such as sret to VS mode in RISC-V, or eret to EL1 in ARM).

[0051] After loading the TEEOS kernel into the security unit Inmate Cell and before TEEOS starts, the process also includes: performing an integrity check on the memory where the TEEOS image is located; and establishing a minimal boot context for the target CPU core, wherein the minimal boot context includes at least an entry address, a stack pointer, a boot parameter address, an exception vector entry, an initial page table base address, and an interrupt masking state.

[0052] Specifically, before the jump, jailhouse establishes a minimal boot context for the target CPU, including the entry address, stack pointer, device tree or boot parameter address, exception vector entry, initial page table base address, and interrupt masking status; at the same time, it performs an integrity check on the memory where the TEEOS image is located, and sets the access attributes of private memory, read-only image area, executable code area, non-executable data area, and shared communication area according to the memory_regions in the description file.

[0053] In the RISC-V architecture, jailhouse removes the target Hart from the Root Cell's scheduling and interrupt routing, sets the Hart's VS entry address and G-stage page table base address, and enters the TEEOS VS mode entry point through sret in HS mode. In the ARM architecture, jailhouse sets HCR_EL2, VTCR_EL2, VTTBR_EL2 and GIC virtualization-related states in EL2, and then enters the TEEOS EL1 entry point through eret.

[0054] 3. Environment Isolation Verification: After TEEOS starts, jailhouse is used to intercept and handle unauthorized access attempts, including: intercepting root cell access to the private memory of the security unit through a two-stage address translation table, intercepting unauthorized peripheral access through memory-mapped I / O traps or I / O port traps, intercepting unauthorized direct memory access through the IOMMU or SMMU, and intercepting unauthorized interrupt injection through the interrupt controller routing table; when an unauthorized access occurs, jailhouse performs at least one of the following actions: denying access, logging the source of access, injecting an exception, resetting the corresponding security unit, or shutting down the corresponding peripheral.

[0055] Specifically, jailhouse continuously monitors all attempts to escalate memory, I / O, DMA, and interrupt accesses, implementing a "software-defined TrustZone".

[0056] Memory access monitoring is implemented through two-stage address translation: Stage-2 page tables for ARM architecture, EPT / NPT for x86 architecture, G-stage page tables for RISC-V architecture, and two-stage translation tables under VZ extension for LoongArch architecture. If the Root Cell accesses TEEOS private memory, or TEEOS accesses Root Cell private memory, and the processor generates a page fault, permission exception, or EPT / G-stage exception at the Hypervisor layer, jailhouse determines whether a violation has occurred based on the exception address, access type, and initiating cell identifier.

[0057] I / O access monitoring is implemented through MMIO mapping, I / O port bitmaps, and interrupt controller routing tables. MMIO physical regions not authorized in the description file are not mapped to corresponding cells; x86 port I / O is captured via port bitmaps or VM-exit; peripheral interrupts are only delivered to the target cell and target CPU specified by irq_routes. For peripherals with DMA capabilities, jailhouse, in conjunction with IOMMU / SMMU, restricts DMA target addresses to prevent devices from bypassing CPU page tables to access unauthorized memory.

[0058] The violation handling methods include: denying the current access and injecting an access exception into the initiating cell; recording the violating cell identifier, physical address, access type, device number, and timestamp; temporarily blocking the corresponding interrupt or disabling the corresponding I / O mapping; and resetting or destroying the corresponding Inmate Cell when the number of consecutive violations exceeds a threshold, while allowing the Root Cell and other security units to continue operating. The above processing logic is completed by the Hypervisor layer and does not rely on the Linux security policy in the Root Cell; therefore, even if Linux is attacked, the isolation boundaries of the security units cannot be modified.

[0059] Step 5: Cross-architecture secure communication (ivshmem), specifically, after TEEOS starts, a data exchange channel is established between Linux and TEEOS using virtual shared memory technology.

[0060] like Figure 2 As shown, after TEEOS starts, it uses virtual shared memory technology to establish a data exchange channel between Linux and TEEOS.

[0061] Without relying on a specific hardware mailbox, a standardized data exchange channel can be established between Linux and TEEOS using virtual shared memory (ivshmem) technology.

[0062] Specifically, the description file declares a physical memory segment with the owner "shared" in `comm_regions`. This shared region is mapped to both the Root Cell and the Inmate Cell, but not to the TEEOS private key area or the Root Cell's ordinary memory area. The shared region is divided into a control area, a request circular queue, a response circular queue, and a data buffer according to a fixed layout. The control area stores the protocol version, queue offset, queue length, read / write pointers, status bits, and session identifier. The request / response circular queue stores the command number, data length, buffer offset, sequence number, and return code. The data buffer carries large blocks of plaintext or ciphertext data.

[0063] The Root Cell (normal unit) and Inmate Cell (secure unit) send requests and responses via the ivshmem doorbell interrupt or equivalent event notification mechanism, ensuring data visibility through memory barriers, cache refresh, or cache consistency attributes. The Linux-side driver writes pending requests to the request queue and performs memory barriers or cache refresh, then notifies TEEOS via the ivshmem doorbell interrupt, MSI / MSI-X, or platform equivalent event. TEEOS processes the request, writes the result to the response queue and data buffer, and then notifies Linux to read it via a reverse doorbell interrupt. For non-cache-consistent platforms, both parties perform cache clean / invalidate before and after queue enqueueing, dequeueing, and data reading; for cache-consistent platforms, visibility is ensured through shared area cache attributes and memory barriers.

[0064] Compared to hardware Mailboxes, ivshmem channels do not rely on specific SoC Mailbox registers, firmware interfaces, or security monitoring call numbers, facilitating reuse across ARM, x86, RISC-V, and LoongArch. Furthermore, shared memory supports larger data blocks and zero-copy transfers, whereas Mailboxes are typically only suitable for transmitting short messages or doorbell signals. ivshmem can also implement asynchronous requests, flow control, and timeout retries through queue depth, sequence numbers, and status bits, reducing cross-architecture adaptation costs.

[0065] In summary, this invention proposes a method for loading a trusted execution environment using jailhouse, the key points of which are as follows: 1. Cross-architecture unified TEE boot framework: A method for building TEEs in ordinary units without relying on hardware-specific security modes (such as non-TrustZone dependencies), but instead utilizing general virtualization extensions (EL2 / VT-x / HS-mode / VZ).

[0066] 2. Static isolation method based on RISC-V H-extension: Specifically refers to the implementation path of hard partitioning the physical HART to TEEOS in RISC-V architecture through HS mode and using two-stage address translation (G-stage paging) to protect the TEE memory.

[0067] 3. Dynamic hardware resource removal technology: During the operation of the main operating system, the Hypervisor dynamically removes the CPU core, interrupt number and memory block and transfers them to the security partition without restarting the system.

[0068] 4. Standardized Security Cell Description File: A unified configuration file format that describes the allocation relationships of CPU, memory, and peripherals under different hardware architectures, used for the automated construction of Inmate Cells.

[0069] 5. Security monitoring logic based on the virtualization layer: jailhouse acts as a security monitor in the Normal World, intercepting and handling defense mechanisms for unauthorized access attempts between the Inmate Cell and the Root Cell.

[0070] The above key points are supported by the aforementioned steps: the cross-architecture unified TEE boot framework is implemented by virtualization privilege level takeover in step 2 and architecture-related jumps in step 4; RISC-V H-extension static isolation is implemented by HART exclusive allocation, HS mode context setting, and G-stage page table in step 3; dynamic removal of hardware resources is implemented by CPU resident, memory mapping deletion, interrupt migration, and DMA domain switching in step 3; the standardized security unit description file is implemented by the unified resource field and arch_map architecture mapping field in step 3; and the security monitoring logic based on the virtualization layer is implemented by two-stage address translation anomalies, MMIO / I / O traps, interrupt routing, and IOMMU / SMMU interception in step 4.

[0071] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0072] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for loading a trusted execution environment using jailhouse, characterized in that, Includes the following steps: Select a physically contiguous memory region from the Linux address space; The jailhouse is used to identify the current hardware architecture and enter the highest privilege level of the current hardware architecture, isolate the memory region from the Linux address space, and intercept access requests to the memory region. Obtain the description file of the security cell and use jailhouse to remove the resources allocated to TEEOS from the Linux visible resource set according to the description file, and configure the security cell Inmate Cell containing the memory region and the resources allocated to TEEOS; Load the TEEOS kernel into the security unit Inmate Cell, and use jailhouse to jump the CPU cores in the resources allocated to TEEOS to the TEEOS entry address according to the reset instruction or context switch instruction of the current hardware architecture. After TEEOS starts, it uses virtual shared memory technology to establish a data exchange channel between Linux and TEEOS, and uses jailhouse to intercept and handle unauthorized access attempts.

2. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, When selecting a physically contiguous memory region from the Linux address space, this is done specifically through the memory mapping parameter memmap or the reserved-memory node in the Device Tree. When using jailhouse to identify the current hardware architecture and enter its highest privilege level to isolate the memory region from the Linux address space, this involves entering the highest privilege level of the current hardware architecture, taking over the exception vector table, Memory Management Unit (MMU), and interrupt control configurations, and completely erasing the memory region from the Linux address space. This restricts the running Linux system to the Root Cell, preventing it from reading or modifying the memory region. The Root Cell is the region in the Linux address space other than the memory region in question.

3. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, The highest privilege levels in the current hardware architecture include: If the current hardware architecture is ARMv8 / v9, then the highest privilege level is EL2 privilege level; If the current hardware architecture is x86, then the highest privilege level is VT-x Root mode; If the current hardware architecture is RISC-V, then the highest privilege level is HS mode; If the current hardware architecture is LoongArch, then the highest privilege level is VZ mode.

4. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, The description file of the security unit adopts a cross-architecture unified field format, including at least a file header field, a CPU set field, a memory region field, an I / O region field, an interrupt routing field, a communication region field, and a security policy field. Among them, the CPU set field describes the processor resources to be allocated using logical CPU identifiers, and is mapped to MPIDR / Core ID under ARM architecture, APIC ID under x86 architecture, Hart ID under RISC-V architecture, or CPU ID under LoongArch architecture through architecture mapping subfields. The I / O region field describes peripheral resources using physical base address, address length, access permissions, DMA isolation domain, and interrupt number.

5. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, When using jailhouse to remove resources allocated to TEEOS from the Linux visible resource set according to the description file, the process includes: freezing ordinary tasks on the target CPU core, migrating or disabling interrupts bound to the target CPU core, placing the target CPU core in a Hypervisor-controlled halted state; deleting the target memory block from the two-stage address translation table of the Root Cell and refreshing the translation backup buffer and necessary cache states; and switching the interrupt routing and DMA access domain of the target peripheral from the ordinary unit Root Cell to the secure unit Inmate Cell, thereby completing the hardware resource removal during the main operating system's operation without requiring a reboot.

6. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, When configuring the Inmate Cell, which includes the memory region and the resources allocated to TEEOS, the following steps are taken: if the current hardware architecture is RISC-V, the physical Hart is hard-splitted to TEEOS in HS mode, the hstatus, hedeleg, hideleg and virtual interrupt control states corresponding to the Hart are set, and hgatp is set to point to the G-stage page table of the Inmate Cell, so that TEEOS is started as a VS mode kernel, and its memory access address is translated to the real physical address through VS stage address translation and then through G-stage address translation.

7. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, When configuring the Inmate Cell, a security unit containing the memory region and resources allocated to TEEOS, the process also includes an I / O tunneling step, specifically including: The mapping of peripheral memory mapping input / output addresses to the secure cell InmateCell address space is established based on the I / O region field and the interrupt routing field; For peripherals with direct memory access capabilities, configure an input / output memory management unit or a system memory management unit so that the peripheral can only access the private memory of the security unit or the authorized shared memory.

8. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, After the TEEOS kernel is loaded into the Inmate Cell security unit, and before TEEOS starts, the process also includes: Perform an integrity check on the memory containing the TEEOS image; A minimum boot context is established for the target CPU core. The minimum boot context includes at least the entry address, stack pointer, boot parameter address, exception vector entry, initial page table base address, and interrupt masking state.

9. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, When jailhouse intercepts and handles unauthorized access attempts, it includes: intercepting root cell access to the private memory of the security unit through a two-stage address translation table; intercepting unauthorized peripheral access through memory-mapped I / O traps or I / O port traps; intercepting unauthorized direct memory access through the IOMMU or SMMU; and intercepting unauthorized interrupt injection through the interrupt controller routing table. When an unauthorized access occurs, jailhouse performs at least one of the following actions: denying access, logging the source of access, injecting an exception, resetting the corresponding security unit, or disabling the corresponding peripheral.

10. The method for loading a trusted execution environment using jailhouse according to claim 1, characterized in that, When establishing a data exchange channel between Linux and TEEOS using virtual shared memory technology, a segment of shared memory is simultaneously mapped to both the ordinary unit Root Cell and the secure unit Inmate Cell. The shared memory is divided into a control area, a request circular queue, a response circular queue, and a data buffer. The ordinary unit Root Cell and the secure unit Inmate Cell send requests and responses through the ivshmem doorbell interrupt or equivalent event notification mechanism, and data visibility is ensured through memory barriers, cache refresh, or cache consistency attributes.

Images