ARM (Advanced RISC Machines) TrustZone architecture for realizing secure world Jailhouse virtualization

Abstract

The invention relates to the technical field of computers, and particularly provides an ARM TrustZone architecture for realizing Jailhouse virtualization of a secure world, which comprises a security monitor, a non-secure world and a secure world, the security monitor comprises a security partition management distributor, and the security partition management distributor is connected with the non-secure world. The non-secure world comprises a virtual machine monitor running at an EL2 exception level, and a host operating system and a plurality of guest operating systems which run at an ELO-EL1 exception level, and the virtual machine monitor provides virtualization service for the non-secure world; the security world comprises a security partition management core running at an SEL2 exception level, and a host security partition and a plurality of customer security partitions running at an SELO-SEL1 exception level, and the security partition management core provides virtualization service for the security world. The technical problem that Jailhouse virtualization isolation cannot be realized in the secure world in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and specifically provides an ARMTrustZone architecture for realizing Jailhouse virtualization of a secure world. Background Art

[0002] TrustZone technology is an important security extension feature on the ARM architecture. It divides the processor state into the non-secure world (Normal World) and the secure world (Secure World). The non-secure world is isolated from the secure world in terms of processor state, memory, and peripherals. The non-secure world and the secure world have multiple exception levels. The non-secure world has user-level, kernel-level, and virtualization-level (such as EL0, EL1, and EL2 in ARMv8) exception levels, where applications run at EL0, operating system kernels run at EL1, and virtual machine monitors run at EL2. The exception levels in the secure world are similar to those in the non-secure world, and there are also user-level and kernel-level (such as SEL0 and SEL1 in ARMv8) exception levels, where secure applications run at SEL0 and trusted operating systems run at SEL1. The Arm v8.4 architecture introduced the Secure EL2 extension (i.e., SEL2 exception level), which added support for virtualization in the secure world. This brings virtualization in the non-secure world to the secure world. The ARMSMMUv3.2 architecture adds secure world second stage transitions, allowing the hypervisor to control the allocation of memory regions to different virtual partitions.

[0003] Jailhouse is a semi-virtualized lightweight virtualization solution led by Siemens. Jailhouse focuses on the partitioning of hardware resources rather than the sharing and virtualization of hardware resources, so it can minimize the overhead and latency introduced by virtualization. According to business needs, resources such as CPU, memory, device interface, interrupt, etc. are allocated before running, and the security and independence of resource allocation are guaranteed during the running process, so that a multi-core CPU can be divided into multiple independent operating environments, each of which can run different operating systems and deploy different businesses.

[0004] At present, armv8 devices using the Jailhouse solution support the isolation brought by virtualization to enhance the security of user privacy in the non-secure world, which can not only meet the system task complexity requirements, but also take into account the system real-time and determinism.

[0005] However, in armv8 devices, Jailhouse cannot achieve this isolation in the secure world, resulting in the following problems:

[0006] 1. Security services need to access hardware resources in the secure world and the non-secure world. These drivers are generally provided by SOC vendors. For original equipment manufacturers (OEMs), the trusted operating system (TEE OS) can be provided by SOC vendors or third parties. If the OEM purchases multiple security services from different software vendors at the same time, they may come from different TEE OS, which will cause the OEM to fall into a situation where multiple TEE OS may need to be integrated. This method requires the OEM to integrate source code from different vendors (TEE OS source code may be closed source). Both the non-secure world and the secure world need to be linked to specific libraries provided by the TEE OS vendor, which limits the portability of trusted applications and also limits the OEM's code integration between different TEE OS vendors.

[0007] 2. The secure firmware in EL3 (i.e., the firmware used in the secure partition) is logically isolated in the same exception level, but it still runs in the same physical environment. It can only achieve logical isolation but not physical isolation, which may face certain security risks. Physical isolation refers to isolating the physical address space of one software image from another software image in space. Logical isolation refers to the isolation of software modules through implementation definition or software configuration. Or, using time allocation, the isolation of software modules in time.

[0008] 3. The TEE OS in SEL1 can access all address spaces of the device's secure world and non-secure world without constraints through the secure monitor. Therefore, if the TEE OS is attacked, all address spaces of the secure world and non-secure world will be threatened. Summary of the invention

[0009] In order to overcome the above defects, the present invention is proposed to solve the technical problem that the prior art cannot realize Jailhouse virtualization isolation in the secure world.

[0010] The present invention provides an ARM TrustZone architecture for realizing Jailhouse virtualization of a secure world, including a secure monitor running at an EL3 exception level, a non-secure world running at an EL0-EL2 exception level, and a secure world running at an SEL0-SEL2 exception level.

[0011] The security monitor includes a secure partition management distributor SPMD, which is built by the ARM secure firmware open source project;

[0012] The non-secure world includes a virtual machine monitor Hypervisor running at the EL2 exception level, a host operating system Host OS and several client operating systems Guest OS running at the ELO-EL1 exception level, and the virtual machine monitor Hypervisor adopts a Jailhouse solution that complies with the ARM FF-A specification to provide virtualization services for the non-secure world;

[0013] The secure world includes a secure partition management core SPMC running at the SEL2 exception level, a host secure partition Host SP running at the SELO-SEL1 exception level, and several customer secure partitions Guest SP. The secure partition management core SPMC adopts the Jailhouse solution that complies with the ARM FF-A specification to provide virtualization services for the secure world.

[0014] Further, the host operating system Host OS and the client operating system Guest OS both include an application program APP running at an EL0 exception level and an operating system kernel Kernel running at an EL1 exception level;

[0015] The host security partition Host SP and the customer security partition Guest SP include a security application Trusted APP running at the SEL0 exception level and a trusted operating system kernel TEE OS Kernel running at the SEL1 exception level.

[0016] Furthermore, the virtualized partitions of the non-secure world implement inter-domain communication through the scheduling of the virtual machine monitor Hypervisor. When an application APP requests the service of another application APP, the communication process includes the following steps:

[0017] The application APP of the requesting party communicates with the kernel Kernel of the operating system of the requesting party by means of system calls, and the application APP of the requested party communicates with the kernel Kernel of the operating system of the requested party by means of system calls;

[0018] The operating system kernel of the requesting party and the operating system kernel of the requested party both use the ARM HVC instruction to fall into the virtual machine monitor Hypervisor;

[0019] The virtual machine monitor Hypervisor first allocates a memory area in the address space of each of the two partitions, and then allocates a readable and writable physical page of the same size and maps it. Finally, a virtual PCI device is used in each partition to perform inter-domain communication through shared memory.

[0020] Furthermore, the virtualized partitions of the secure world implement inter-domain communication through the scheduling of the secure partition management core SPMC. When a secure application Trusted APP requests the service of another secure application Trusted APP, the communication process includes the following steps:

[0021] The requesting party's secure application Trusted APP communicates with the requesting party's trusted operating system kernel TEE OSKernel by means of system calls, and the requested party's secure application Trusted APP communicates with the requested party's trusted operating system kernel TEE OS Kernel by means of system calls;

[0022] Both the trusted operating system kernel TEE OS Kernel of the requesting party and the trusted operating system kernel TEEOS Kernel of the requested party use ARM HVC instructions to fall into the secure partition management core SPMC;

[0023] The secure partition management core SPMC first allocates a memory area in the address space of each of the two partitions, and then allocates a readable and writable physical page of the same size and maps it. Finally, a virtual PCI device is used in each partition to communicate between domains through shared memory.

[0024] Furthermore, the virtualized partition of the non-secure world and the virtualized partition of the secure world realize inter-domain communication through the path of the virtual machine monitor Hypervisor, the secure partition management distributor SPMD and the secure partition management core SPMC. When the application APP requests the service of the secure application Trusted APP, the communication process includes the following steps:

[0025] The application APP communicates with its corresponding operating system kernel Kernel by means of system calls, and the secure application Trusted APP communicates with its corresponding trusted operating system kernel TEE OS Kernel by means of system calls;

[0026] The operating system kernel uses the ARM HVC instruction to fall into the virtual machine monitor Hypervisor, and the trusted operating system kernel TEE OS Kernel uses the ARM HVC instruction to fall into the secure partition management core SPMC;

[0027] The virtual machine monitor Hypervisor uses the ARM SMC instruction to fall into the secure monitor, and the secure partition management core SPMC uses the ARM SMC instruction to fall into the secure partition management distributor SPMD to realize inter-domain communication in the secure monitor.

[0028] Beneficial effects of the present invention:

[0029] 1. Original equipment manufacturers (OEMs) can run multiple TEE OS or security services simultaneously in the secure world, which fundamentally solves the portability of trusted applications and the problem of limited code integration between different TEE OS vendors for OEMs.

[0030] 2. After using this solution, the secure firmware in EL3 can be distributed to different secure partitions and physically isolated by the jail of SEL2. That is, the firmware used by the secure partition can be isolated from EL3 (placed in the secure partition SP) by the jail, and the jail can control the corresponding part of the physical address space to be visible to the given secure partition.

[0031] 3. Since the jail can control the corresponding part of the physical address space visible to a given security partition, when the TEE OS is attacked, it will only affect a small address space allocated by the jail of SEL2 for the security partition, and will not pose a threat to the entire physical address space of the device. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The disclosure of the present invention will become more easily understood with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present invention. In addition, similar numbers in the figures are used to represent similar components, among which:

[0033] Figure 1 It is a block diagram of the ARM TrustZone architecture of the present invention;

[0034] Figure 2 It is a schematic diagram of the principle of realizing inter-domain communication in the non-secure world of the present invention;

[0035] Figure 3 It is a schematic diagram of the principle of realizing inter-domain communication in the secure world of the present invention;

[0036] Figure 4 It is a schematic diagram of the principle of realizing inter-domain communication between the non-secure world and the secure world of the present invention. DETAILED DESCRIPTION

[0037] Some embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood by those skilled in the art that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the protection scope of the present invention.

[0038] Example 1

[0039] Figure 1: is a block diagram of the ARM TrustZone architecture of the present invention. Figure 1 As shown, an ARM TrustZone architecture for realizing secure world Jailhouse virtualization in this embodiment mainly includes a secure monitor running at EL3 exception level, a non-secure world running at EL0-EL2 exception level, and a secure world running at SEL0-SEL2 exception level.

[0040] 1.EL3 (Secure Monitor)

[0041] EL3 is the highest privilege level and is responsible for switching between secure and non-secure modes. It is in a secure state and can access both the non-secure world and the secure world.

[0042] The security monitor includes the secure partition manager distributor (SPMDispatcher, SPMD) firmware required for secure world virtualization. SPMD is built by the ARM Secure Firmware (ARM Trusted Firmware, ATF) open source project. It is responsible for loading SPMC and configuring resource allocation for secure partitions. It is also the medium for SPMC to communicate with the non-secure world.

[0043] SPMD is a firmware module integrated in the security monitor, and the security monitor communicates with the SPMC through SPMD.

[0044] In this embodiment, the SPM specified by ARM is composed of the SPMC in SEL2 and the SPMD in EL3, both of which can access the entire physical address space and are components of the Trusted Computing Base (TCB).

[0045] In one embodiment, SPMD runs at EL3, and its functions are: responsible for initializing SPMC in the startup process; distributing FF-A calls from the non-secure world to SPMC; distributing FF-A calls from SPMC to the non-secure world.

[0046] In one embodiment, SPMC runs in SEL2, and its functions are: to initialize and isolate the virtualized partition SP of the secure world at startup; to isolate the virtualized partition SPs of different secure worlds at runtime; to be responsible for the communication between the virtualized partition SPs of different secure worlds and the communication between the virtualized partition SP of the secure world and the virtualized partition VM of the non-secure world.

[0047] 2. Non-secure world

[0048] The non-secure world includes a hypervisor running at the EL2 exception level, a host operating system Host OS running at the ELO-EL1 exception level, and several guest operating systems Guest OS ( Figure 1 In the figure, the host operating system Host OS and the guest operating system Guest OS both include an application program APP running at the EL0 exception level and an operating system kernel Kernel running at the EL1 exception level.

[0049] The hypervisor uses the Jailhouse solution that complies with the ARM FF-A specification to provide virtualization services for the non-secure world. The virtualized partitions it manages are the host operating system Host OS and the client operating system Guest OS.

[0050] 3. Safe World

[0051] The secure world includes the secure partition management core (SPM Core, SPMC) running at the SEL2 exception level, a host secure partition Host SP running at the SELO-SEL1 exception level, and several client secure partitions Guest SP ( Figure 1 In the figure, the host security partition Host SP and the customer security partition Guest SP include a security application Trusted APP running at the SEL0 exception level and a trusted operating system kernel TEE OS Kernel running at the SEL1 exception level.

[0052] In one implementation, the client security partition Guest SP may also support simpler programs that are not kernel-dependent and can run directly in a bare metal environment, such as a secure platform driver Platform Driver or a bare metal security service program Secure Servise.

[0053] SPMC adopts the Jailhouse solution that complies with the ARM FF-A specification to provide virtualization services for the secure world. The virtualization partitions it manages are the host security partition Host SP and the customer security partition Guest SP.

[0054] In this embodiment, the FF-A specification proposed by ARM provides standardized interfaces for different sandboxes (virtualized partitions of non-secure world, virtualized partitions of secure world, etc.) running in ARM architecture devices, so that the interfaces between different partitions are standardized. The FF-A specification defines the standardization of software architecture and ABI binary communication interface (data structure), the FF-A between modules is the ABI communication standard, and the FF-A driver is the FF-A driver, which implements FF-A ABI communication.

[0055] In one implementation, in order to reduce the code integration cost, improve the transparency of the secure world configuration changes to the non-secure world, and improve the portability of the secure partition, the role of using the SEL2-Jailhouse of the FF-A specification in this embodiment is:

[0056] Isolate the firmware in EL3 from the trusted operating system in SEL1;

[0057] Migrate components from different vendors from EL3 to SEL1 or SEL0 to achieve firmware isolation and meet the principle of least privilege that software components must be able to access only areas and system resources in the physical address space;

[0058] Standardize the interfaces for communication between various software, including those in the secure world and the non-secure world.

[0059] This solution uses the Secure EL2 extension function introduced by the Armv8.4 architecture to implement Jailhouse's SEL2 secure virtualization technology on the ARMTrustZone architecture, realize the componentization and hardware isolation of the secure world, and meet the principle of least privilege in system security.

[0060] Example 2

[0061] Based on the ARM TrustZone architecture proposed in Example 1, different virtualized partitions can communicate with each other or request services, specifically including the following three types of communications.

[0062] 1. Figure 2 FIG. 1 is a schematic diagram of the principle of realizing inter-domain communication in the non-secure world of the present invention. Figure 2 As shown, the virtualized partitions of the non-secure world realize inter-domain communication through the scheduling of the virtual machine monitor Hypervisor. When an application APP requests (hereinafter referred to as "the requesting application APP") the service of another application APP (hereinafter referred to as "the requested application APP"), the communication process includes the following steps:

[0063] The application APP of the requesting party communicates with the kernel Kernel of the operating system of the requesting party by means of system calls, and the application APP of the requested party communicates with the kernel Kernel of the operating system of the requested party by means of system calls;

[0064] The operating system kernel of the requesting party and the operating system kernel of the requested party both use the ARM HVC instruction to fall into the virtual machine monitor Hypervisor;

[0065] The virtual machine monitor Hypervisor first allocates a memory area in the address space of each of the two partitions, and then allocates a readable and writable physical page of the same size and maps it. Finally, a virtual PCI device is used in each partition to perform inter-domain communication through shared memory.

[0066] 2. Figure 3 FIG. 1 is a schematic diagram of the principle of realizing inter-domain communication in the secure world of the present invention. Figure 3 As shown, the virtualized partitions of the secure world realize inter-domain communication through the scheduling of the secure partition management core SPMC. When a secure application TrustedAPP (hereinafter referred to as "the secure application TrustedAPP of the requesting party") requests the service of another secure application TrustedAPP (hereinafter referred to as "the secure application TrustedAPP of the requested party"), the communication process includes the following steps:

[0067] The requesting party's secure application Trusted APP communicates with the requesting party's trusted operating system kernel TEE OSKernel by means of system calls, and the requested party's secure application Trusted APP communicates with the requested party's trusted operating system kernel TEE OS Kernel by means of system calls;

[0068] Both the trusted operating system kernel TEE OS Kernel of the requesting party and the trusted operating system kernel TEEOS Kernel of the requested party use ARM HVC instructions to fall into the secure partition management core SPMC;

[0069] The security partition management core SPMC first allocates a memory area in the address space of the virtualized partitions of the two security worlds respectively, and then allocates a readable and writable physical page of the same size and maps it. Finally, a virtual PCI device is used in each partition to perform inter-domain communication through shared memory.

[0070] 3. Figure 4 FIG. 1 is a schematic diagram of the principle of realizing inter-domain communication between the non-secure world and the secure world of the present invention. Figure 4As shown, the virtualized partition of the non-secure world and the virtualized partition of the secure world realize inter-domain communication through the path of the virtual machine monitor Hypervisor, the secure partition management distributor SPMD and the secure partition management core SPMC. When the application APP requests the service of the secure application Trusted APP, the communication process includes the following steps:

[0071] The application APP communicates with its corresponding operating system kernel Kernel by means of system calls, and the secure application Trusted APP communicates with its corresponding trusted operating system kernel Tee OS Kenel by means of system calls;

[0072] The operating system kernel uses the ARM HVC instruction to fall into the virtual machine monitor Hypervisor, and the trusted operating system kernel TEE OS Kernel uses the ARM HVC instruction to fall into the secure partition management core SPMC;

[0073] The virtual machine monitor Hypervisor uses the ARM SMC instruction to fall into the secure monitor, and the secure partition management core SPMC uses the ARM SMC instruction to fall into the secure partition management distributor SPMD. The secure partition management distributor SPMD can communicate directly with other components in EL3, complete the switching between secure and non-secure states in the secure monitor, and realize inter-domain communication.

[0074] Example 3

[0075] Based on the ARM TrustZone architecture proposed in Example 1, the solution adopted by SPMC is to comply with the Jailhouse of FF-A and run in SEL2. SPMD is implemented using the SPMD provided in the ARM Trusted Firmware (ATF) and integrated in the ATF firmware of EL3.

[0076] ATF provides the option to build a secure partition manager based on the FF-A specification:

[0077] 1. SPD = spmd: Select SPMD as the FF-A specification scheduler for the non-secure world and the secure world. No other schedulers can be enabled.

[0078] 2.SPMD_SPM_AT_SEL2: Adjust the execution level of SPMC to SEL1 or SEL2. It is enabled by default when SPD=spmd is selected.

[0079] 3.CTX_INCLUDE_EL2_REGS: Allows saving the context of EL2 system registers when entering SPMC and restoring the context of system registers when leaving SPMC. This option must be used when SPMD_SPM_AT_SEL2 is enabled.

[0080] 4.SP_LAYOUT_FILE: This option provides a SP partition image file and a manifest file in dts format. After enabling SPMD_SPM_AT_SEL2, if Jailhouse needs to load multiple secure partitions, this option is required.

[0081] 5.BL32: Specify the image file for SPMC. In this solution, you need to specify the path to the Jailhouse hypervisor binary file.

[0082] 6.BL33: Specifies the bootloader of the non-secure world, such as U-boot, UEFI. Interacts with Jailhouse as SPMC at runtime.

[0083] In summary, in the Arm V8.4 system, the ATF command example for building SPMC with Jailhouse as SEL2 is as follows:

[0084] make\ / / Start building

[0085] CROSS_COMPILE = aarch64-none-elf-\ / / Specify the cross-compilation tool chain

[0086] SPD = spmd\ / / Select SPMD as the FF-A specification scheduler for the non-secure world and the secure world

[0087] CTX_INCLUDE_EL2_REGS=1\ / / Allows saving the context of EL2 system registers when entering SPMC and restoring the context of system registers when leaving SPMC.

[0088] ARM_ARCH_MINOR=84\ / / Specify ARM architecture version

[0089] BL32=<path-to-swd-Jailhouse.bin> / / Specify Jailhouse as the SPMC image file

[0090] BL33= <path-to-nwd-binary>\ / / Specify the bootloader of the non-secure world

[0091] SP_LAYOUT_FILE = sp_layout.json\ / / Specify the resource allocation file of the security partition

[0092] PLAT=fvp\ / / Specify the ATF build platform as fvp

[0093] all fip / / Build as firmware image package

[0094] If Secure Boot is enabled:

[0095] make\ / / Start building

[0096] CROSS_COMPILE = aarch64-none-elf-\ / / Specify the cross-compilation tool chain

[0097] SPD = spmd\ / / Select SPMD as the FF-A specification scheduler for the non-secure world and the secure world

[0098] CTX_INCLUDE_EL2_REGS=1\ / / Allows saving the context of EL2 system registers when entering SPMC and restoring the context of system registers when leaving SPMC.

[0099] ARM_ARCH_MINOR=84\ / / Specify ARM architecture version

[0100] BL32=<path-to-swd-Jailhouse.bin> / / Specify Jailhouse as the SPMC image file

[0101] BL33= <path-to-nwd-binary>\ / / Specify the bootloader of the non-secure world

[0102] SP_LAYOUT_FILE = sp_layout.json\ / / Specify the resource allocation file of the security partition

[0103] MBEDTLS_DIR= <path-to-mbedtls-lib>\ / / Specify the compiled encryption component

[0104] TRUSTED_BOARD_BOOT=1\ / / Specify the firmware as secure boot mode

[0105] COT=dualroot\ / / Specify the dual boot mode of the firmware

[0106] ARM_ROTPK_LOCATION=devel_rsa\ / / Specify ROTPK to generate hash in rsa_sha256 format

[0107] ROT_KEY = plat / arm / board / common / rotpk / arm_rotprivk_rsa.pem\ / / Specify the security root key

[0108] GENERATE_COT=1\ / / Generate a trusted chain for verifying firmware in secure boot

[0109] PLAT=fvp\ / / Specify the ATF build platform as fvp

[0110] all fip / / Build as firmware image package

[0111] So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.

Claims

1. An ARM TrustZone architecture for implementing Jailhouse virtualization, characterized in that: It includes a secure monitor running at the EL3 exception level, a non-secure world running at the EL0-EL2 exception level, and a secure world running at the SEL0-SEL2 exception level. The security monitor includes a secure partition management distributor SPMD, which is built by the ARM secure firmware open source project; The non-secure world includes a virtual machine monitor Hypervisor running at the EL2 exception level, a host operating system Host OS and several client operating systems Guest OS running at the ELO-EL1 exception level, and the virtual machine monitor Hypervisor adopts a Jailhouse solution that complies with the ARM FF-A specification to provide virtualization services for the non-secure world; The secure world includes a secure partition management core SPMC running at the SEL2 exception level, a host secure partition Host SP running at the SELO-SEL1 exception level, and several customer secure partitions Guest SP. The secure partition management core SPMC adopts the Jailhouse solution that complies with the ARM FF-A specification to provide virtualization services for the secure world.

2. The ARM TrustZone architecture for implementing Jailhouse virtualization according to claim 1, characterized in that: The host operating system Host OS and the client operating system Guest OS both include an application program APP running at an EL0 exception level and an operating system kernel Kernel running at an EL1 exception level; The host security partition Host SP and the customer security partition Guest SP include a security application Trusted APP running at the SEL0 exception level and a trusted operating system kernel TEE OS Kernel running at the SEL1 exception level.

3. The ARM TrustZone architecture for implementing Jailhouse virtualization according to claim 2, characterized in that: The virtualized partitions in the non-secure world communicate with each other through the scheduling of the virtual machine monitor Hypervisor. When an application APP requests the service of another application APP, the communication process includes the following steps: The application APP of the requesting party communicates with the kernel Kernel of the operating system of the requesting party by means of system calls, and the application APP of the requested party communicates with the kernel Kernel of the operating system of the requested party by means of system calls; The operating system kernel of the requesting party and the operating system kernel of the requested party both use the ARM HVC instruction to fall into the virtual machine monitor Hypervisor; The virtual machine monitor Hypervisor first allocates a memory area in the address space of each of the two partitions, and then allocates a readable and writable physical page of the same size and maps it. Finally, a virtual PCI device is used in each partition to perform inter-domain communication through shared memory.

4. The ARM TrustZone architecture for implementing Jailhouse virtualization according to claim 2, characterized in that: The virtualized partitions of the secure world implement inter-domain communication through the scheduling of the secure partition management core SPMC. When a secure application Trusted APP requests the service of another secure application Trusted APP, the communication process includes the following steps: The requesting party's secure application Trusted APP communicates with the requesting party's trusted operating system kernel TEE OS Kernel by means of system calls, and the requested party's secure application Trusted APP communicates with the requested party's trusted operating system kernel TEE OS Kernel by means of system calls; Both the trusted operating system kernel TEE OS Kernel of the requesting party and the trusted operating system kernel TEE OS Kernel of the requested party use ARM HVC instructions to fall into the secure partition management core SPMC; The secure partition management core SPMC first allocates a memory area in the address space of each of the two partitions, and then allocates a readable and writable physical page of the same size and maps it. Finally, a virtual PCI device is used in each partition to communicate between domains through shared memory.

5. The ARM TrustZone architecture for implementing Jailhouse virtualization according to claim 2, characterized in that: The virtualized partitions of the non-secure world and the virtualized partitions of the secure world communicate with each other through the channels of the virtual machine monitor Hypervisor, the secure partition management distributor SPMD and the secure partition management core SPMC. When the application APP requests the service of the secure application Trusted APP, the communication process The following steps are involved: The application APP communicates with its corresponding operating system kernel Kernel by means of system calls, and the secure application Trusted APP communicates with its corresponding trusted operating system kernel TEE OS Kernel by means of system calls; The operating system kernel uses the ARM HVC instruction to fall into the virtual machine monitor Hypervisor, and the trusted operating system kernel TEE OS Kernel uses the ARM HVC instruction to fall into the secure partition management core SPMC; The virtual machine monitor Hypervisor uses the ARM SMC instruction to fall into the secure monitor. The full partition management core SPMC uses the ARM SMC instruction to fall into the secure partition management distributor SPMD. Implementing inter-domain communication in a security monitor.

Images