Management method for device-to-device peripheral, computing device and computer program product

Abstract

The embodiment of the invention provides an equipment direct connection peripheral management method, which integrates an equipment direct connection driver import process into a safe starting process, and ensures equipment direct connection driver import safety by means of a trust chain established by step-by-step signature verification in the safe starting process. The target firmware directly indicates the security virtual machine manager to complete the security state configuration of the PCIe controller and the security mounting of the target device, so that the security of the device to be directly communicated with the peripheral is ensured.

Description

Technical Field

[0001] This specification relates to the field of computer technology, specifically to device pass-through technology in the field of computer technology, and more specifically, to a management method for device pass-through peripherals, computing devices, and computer program products. Background Technology

[0002] Device passthrough is a virtualization technology that allows PCIe (Peripheral Component Interconnect express) devices on the host computer to be directly mounted on a virtual machine. This enables the virtual machine to directly access PCIe devices without requiring virtualization through a Virtual Machine Monitor (VMM), accelerating the interaction between the virtual machine and PCIe devices, reducing latency, and improving overall system performance. With the widespread adoption of device passthrough technology, ensuring its security during use has become a key concern. Summary of the Invention

[0003] This specification provides a management method, computing device, and computer program product for device pass-through to peripherals, in order to ensure the security of the control process for device pass-through to peripherals in the absence of dedicated security hardware.

[0004] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions:

[0005] Firstly, one embodiment of this specification provides a management method for device pass-through to peripherals, applied to a computing device, the computing device including a processor and an RC device, the processor being used to construct a trusted execution environment subsystem, the RC device including a PCIe controller and configuration registers, the management method for device pass-through to peripherals including:

[0006] During the secure boot process, the target firmware reads the value of the configuration register. When the value of the configuration register indicates that the device pass-through function is enabled, the device pass-through driver is imported. The device pass-through driver is the driver for the device pass-through function. The target firmware includes trusted firmware.

[0007] In response to the first request to pass through and mount the target device, the target firmware sends a second request to the security virtual machine manager. The second request instructs the security virtual machine manager to configure the PCIe controller mounting the target device to a secure state, and to instruct the security virtual machine manager to mount the target device under the root node of the RC device after unmounting the peripheral currently mounted on the PCIe controller and after the security verification of the target device is passed. The PCIe controller in the secure state rejects the mounting of non-secure peripherals, and the security virtual machine manager runs in the trusted execution environment subsystem.

[0008] Secondly, one embodiment of this specification also provides a computing device, including: a processor and an RC device, the processor being configured to construct a trusted execution environment subsystem, and the RC device including a PCIe controller and configuration registers; wherein the processor is configured to execute the device pass-through peripheral management method described in any of the preceding embodiments.

[0009] Thirdly, one embodiment of this specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the device pass-through peripheral management method described above.

[0010] Fourthly, embodiments of this specification provide a computer program product or computer program, the computer program product including a computer program stored in a computer-readable storage medium; the processor of the computer device reads the computer program from the computer-readable storage medium, and when the processor executes the computer program, it implements the steps of the above-described management method for device pass-through to peripherals. Optionally, the computer program may be stored in a computer-readable storage medium or in the cloud; the processor of the computer device reads the computer program from the readable storage medium or in the cloud.

[0011] As can be seen from the above technical solutions, the device pass-through peripheral management method provided in this specification integrates the device pass-through driver import process into the secure boot process. By leveraging the trust chain established through step-by-step signature verification during secure boot, the security of the device pass-through driver import is ensured. Furthermore, by directly instructing the secure virtual machine manager through the target firmware to complete the secure state configuration of the PCIe controller and the secure mounting of the target device, the security of the device pass-through peripheral is guaranteed. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this specification. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0013] Figure 1 This diagram illustrates the relationship between tenants and the cloud platform.

[0014] Figure 2 This is a schematic diagram of a trusted firmware.

[0015] Figure 3 This is a flowchart illustrating a secure startup method provided as one embodiment of this specification.

[0016] Figure 4 This diagram illustrates a feasible process for transferring a target device from a regular virtual machine to a secure virtual machine, as provided in one embodiment of this specification.

[0017] Figure 5 This diagram illustrates a feasible transfer process of control authority for a system memory management unit provided in one embodiment of this specification.

[0018] Figure 6 This is a flowchart illustrating a method for managing device direct access to peripherals, provided as one embodiment of this specification.

[0019] Figure 7 This is a flowchart illustrating a method for managing device direct access to peripherals, provided as one embodiment of this specification.

[0020] Figure 8 This is a schematic diagram of the architecture of a PCIe system provided for one embodiment of this specification.

[0021] Figure 9 This is a schematic diagram of the structure of a computing device provided for one embodiment of this specification. Detailed Implementation

[0022] Unless otherwise defined, the technical or scientific terms used in the embodiments of this specification shall have the ordinary meaning understood by one of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in the embodiments of this specification do not indicate any order, quantity, or importance, but are merely used to avoid confusion of constituent elements.

[0023] Unless the context otherwise requires, throughout this specification, "a plurality of" means "at least two," and "including" is interpreted as open-ended or encompassing, that is, "including, but not limited to." In the description of this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this specification. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example.

[0024] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0025] Overview

[0026] Device passthrough technology is widely used in scenarios such as cloud platforms because it accelerates the interaction between virtual machines and PCIe devices, reduces latency, and improves overall system performance. A cloud platform is an infrastructure service that provides on-demand allocation of computing resources (such as servers, storage, databases, and networks). It abstracts and dynamically schedules physical resources through virtualization technology, allowing tenants to access the necessary IT (Information Technology) resources on demand and pay based on usage.

[0027] When using software services provided by a cloud platform, tenants can create virtual machines (VMs) within the platform to access these services and resources. This approach achieves resource isolation between tenants, preventing malicious attacks or data breaches and ensuring resource security. Furthermore, providing software services to tenants through VM creation also facilitates flexible expansion and customization of IT resources to meet their needs. (Reference) Figure 1 , Figure 1 This diagram illustrates the relationship between tenants and the cloud platform, with multiple tenants (e.g.) Figure 1 When tenants A, B, and C use the cloud platform for the first time, they can create their own virtual machines 1 through 3 based on virtualization technology. These virtual machines can be managed by the cloud platform's hypervisor, for example, the hypervisor manages the virtual machines' physical memory (e.g., ...). Figure 1The virtual machine memory control (in the storage of the cloud). After tenants have created their respective virtual machines, they can use the software services and resources provided by the cloud platform based on their respective virtual machines. It is understandable that... Figure 1 Although the document shows three tenants and three virtual machines corresponding to those three tenants, Figure 1 This is for illustrative purposes only. In actual applications, the number of virtual machines and tenants can be more or less, and this specification does not exhaustively list them all. In addition, the processor in the computing device used to build the cloud platform can also be equipped with components for trusted computing, such as a cryptographic engine and a key storage unit, to ensure the security and trustworthiness of the computing device and its operation.

[0028] With the rapid development of trusted computing technology, the demand for peripheral access from cloud platforms is surging. Trusted computing aims to protect data privacy during processing by ensuring sensitive data is not leaked or tampered with through hardware-supported isolation technologies (such as trusted execution environments). As the infrastructure providing computing services, cloud platforms face increasingly stringent user demands for data security and privacy, especially when dealing with sensitive information. Access to peripherals such as encryption modules, security hardware, and network devices has become a crucial component of data security. Against this backdrop, the surge in demand for cloud platform peripheral access primarily stems from the need for efficient and secure hardware support for confidential computing. Traditional cloud platform architectures typically use virtualization to allocate resources, while confidential computing requires stricter hardware isolation and security guarantees. This has prompted cloud service providers to increase their support for dedicated hardware (such as security encryption chips, network interface cards, graphics processors, and HBM (High Bandwidth Memory)). Furthermore, the demand for peripheral access is also driven by the increasing complexity of computing tasks, the volume of data, and industry compliance requirements. To meet these demands, cloud platforms need to continuously optimize the management, allocation, and secure access strategies of hardware resources to support a more secure trusted computing environment. Meanwhile, in order to improve the speed at which users' virtual machines access PCIe devices and improve system performance, the cloud platform can use device pass-through technology to mount PCIe devices on the virtual machines created by users, so that the virtual machines can access PCIe devices directly without going through the virtual machine manager.

[0029] To ensure the security of device passthrough functionality during startup and use, dedicated security hardware, such as a Secure Coprocessor (SCP), is often used to verify the security of mounted PCIe devices and virtual machines. This requires... Figure 1The computing device shown includes a dedicated security hardware component in addition to the processor (which can also be called an application processor (AP) because it is responsible for running the applications required by the user). This results in a higher overall hardware cost for the computing device. Furthermore, the processor and the dedicated security hardware need to transmit the necessary interactive information through technologies such as inter-core communication, making the overall communication architecture of the computing device more complex.

[0030] To ensure the security of the device passthrough startup process without dedicated security hardware, thereby reducing the hardware and communication complexity of computing devices, this specification provides a secure startup method. This method is applied to a computing device including a processor and a system memory management unit. During the startup process, the value of the processor's first register indicates whether the processor's device passthrough function is enabled. If the first register value indicates that the processor's device passthrough function is enabled, the processor's target driver is imported, and the import result of the target driver is written to a measurement file. Then, the control of the system memory management unit is transferred from the insecure virtual machine manager to the secure virtual machine manager. Finally, if the measurement file verification is successful, a user's device passthrough request for the target device is received, and the target device mounted on a regular virtual machine is transferred to the secure virtual machine. Thus, the user can use the secure virtual machine to pass through and access the target device. In the above process, a trusted execution environment subsystem is implemented based on the processor. During the startup process, the control authority of the system memory management unit and the target device are transferred from the ordinary execution environment to the trusted execution environment (that is, the control authority of the system memory management unit is transferred to the secure virtual machine manager, and the target device is transferred to the secure virtual machine). In this way, in the absence of dedicated security hardware (such as a secure coprocessor (SOP)), the trusted execution environment subsystem implemented based on the processor can ensure the secure startup of the processor's device passthrough function. On the basis of ensuring the secure and reliable startup of the device passthrough function, the hardware requirements of the computing device are reduced.

[0031] In addition, during secure boot, the system memory management unit can follow the traditional initialization process. That is, the non-secure virtual machine manager in the Rich Execution Environment (REE) subsystem can boot and initialize the system memory management unit. After initialization, the control of the system memory management unit is transferred to the secure virtual machine manager in the Trusted Execution Environment (TEE) subsystem. In this way, there is no need to load and boot the system memory management unit driver in the Trusted Execution Environment, which helps to simplify the processing logic of the Trusted Execution Environment subsystem, reduce the algorithm burden of the Trusted Execution Environment subsystem, and reduce the hardware requirements of the Trusted Execution Environment subsystem.

[0032] Similarly, during the startup process, the target device (i.e., the peripheral device that requires device passthrough) can first be mounted under a regular virtual machine in the Trusted Execution Environment (TEE) subsystem. Then, the insecure virtual machine manager transfers the target device mounted under the regular virtual machine to the secure virtual machine, thus enabling the target device to be mounted under the secure virtual machine. In this way, there is no need to make complex adjustments to the relevant drivers of the secure virtual machine in the TEE subsystem, nor is there a need to add target device initialization and other related logic to the relevant drivers of the secure virtual machine. This helps to simplify the processing logic of the TEE subsystem, reduce the algorithm burden of the TEE subsystem, and reduce the hardware requirements of the TEE subsystem.

[0033] Meanwhile, corresponding solutions were also proposed for the lifecycle management of devices that pass through peripherals, the control and management of PCIe controllers and related software and hardware in the absence of dedicated security hardware.

[0034] Based on the above concept, this specification provides a secure boot method. The secure boot method will be described exemplarily below after introducing the relevant technical terms that may be involved in the secure boot method.

[0035] Possible technical terms:

[0036] Trusted Firmware (TF) is a security solution that divides the privilege levels during the boot and operation of a computing device. These privilege levels, combined with a secure hardware architecture, work together to ensure the security of the computing device's boot process. Specifically, such as... Figure 2As shown, Trusted Firmware technology divides privilege levels into four levels: EL0 (Exception Level 0) to EL3. The privilege levels increase sequentially from EL0 to EL3. EL0, EL1, and EL2 can be further divided into NS-ELx (NoneSecure ELx, x = 0, 1, 2, i.e., non-secure world ELx) and S-ELx (Secure ELx, x = 0, 1, 2, i.e., secure world ELx), while EL3 only has one type: Secure World EL3. In some cases, the firmware required for the startup process of a computing device may include BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, and the Management Module (MM) firmware.

[0037] In existing ARM-based software architectures, from a security perspective, management module firmware is needed to provide relevant security applications. These security applications include secure variable handling, secure firmware upgrades, and interaction between the secure and insecure worlds. Management module firmware can help system administrators handle application requests from the insecure world to the secure world, thereby improving system security.

[0038] BL1 firmware, also known as Trusted Boot ROM, is the earliest firmware to run during the boot process. It is stored in the processor's ROM (Read-Only Memory) and is not located in the computer device's BIOS. In some types of trusted firmware technologies, BL1 firmware serves as the root of trust. BL1 firmware can be used to initialize the core hardware of the computing device (such as Trusted SRAM, serial ports, etc.) and locate the BL2 hardware. In some cases, BL1 firmware will verify the signature of the BL2 firmware. BL1 firmware runs at the EL3 privilege level.

[0039] The BL2 firmware can be called Trusted Boot Firmware or Platform Initialization Firmware. Like the BL1 firmware, BL2 runs at the EL3 privilege level. A significant difference between BL2 and BL1 is that BL2 can be stored on an external trusted storage device, and its trustworthiness is based on the verification performed by the BL1 firmware. The BL2 firmware initializes some critical security hardware and software frameworks. After initialization, the BL2 firmware locates BL31.

[0040] The BL31 firmware can be called EL3 Runtime Firmware. The BL31 firmware also runs on the EL3 privilege level and is the last security bastion of the EL3 privilege level. Unlike the BL1 and BL2 firmware, which are one-time runs, the BL31 firmware continuously provides security-related services to the non-secure world through SMC (Secure Monitor Call).

[0041] The BL32 firmware can include the OPTee OS (Open Portable Trusted Execution Environment Operator System) and trusted applications. The BL32 firmware runs on S-EL1, and the trusted applications on the BL32 firmware run on S-EL0. In some cases, after the OPTee OS finishes running, it returns to the BL31 firmware on EL3. The BL31 firmware then locates the BL33 firmware and can also verify the signature of the BL33 firmware.

[0042] The BL33 firmware can include firmware running in the normal world (non-trusted firmware). It can include UEFI (Unified Extensible Firmware Interface) firmware for desktops and servers, or U-boot (a bootloader for embedded systems), or even the Linux kernel and basic input / output system (BIOS) firmware. In the normal world, the execution privileges of EL0, EL1, EL2, and EL3 increase sequentially. The UEFI firmware is configured to run at EL2 level in the normal world, while the OP-TEE is configured to run at EL1 level in the secure world. When entering UEFI (BL33) boot mode, the OP-TEE has already booted, and communication between UEFI and OP-TEE can be achieved through the secure monitorcall (SMC) interface. Therefore, during UEFI boot, when verifying the integrity and security of the image file, certain functions can be implemented by triggering the SMC method in the normal world to call the corresponding OP-TEE interface in the secure world. This allows the verification process involving the image file to be passed to the secure world for verification, and the verification result to be returned to the normal world. After the BL33 firmware boot and load are complete, the operating system (OS) or kernel can be booted and loaded, completing the device boot process.

[0043] Management Module (MM) firmware can be a type of firmware used to provide related security applications, including security variable handling, secure firmware upgrades, and interaction between the secure and insecure worlds. MM firmware helps system administrators handle application requests from the insecure world to the secure world, thereby improving system security.

[0044] Understandable Figure 2 This document illustrates a feasible trusted firmware, including firmware types and a feasible boot process. In some embodiments, the trusted firmware may include more or fewer firmware components, and the boot process may vary accordingly. For example, in some embodiments, the trusted firmware may not include management module firmware; in other embodiments, the trusted firmware may include firmware types not mentioned above. This specification does not limit the scope of these embodiments. In some embodiments, firmware running at the EL3 privilege level (e.g., BL1, BL2, and BL31 firmware) can be collectively referred to as Base Firmware (BF).

[0045] The Baseboard Management Controller (BMC) is a management controller independent of the server's main processor. It enables hardware-level system monitoring and remote management via the IPMI (Intelligent Platform Management Interface) standard. Its core functions include hardware status monitoring, out-of-band management, fault response, and secure communication.

[0046] Rich Execution Environment (REE) subsystem: This is a regular execution environment that runs an operating system and can handle non-sensitive tasks.

[0047] The Trusted Execution Environment (TEE) subsystem is a hardware-isolated secure execution space that can protect the confidentiality and integrity of code and data through technologies such as Trust Zone or SGC, providing a protected execution space for sensitive operations (such as encryption key processing, biometric authentication, digital rights management, etc.).

[0048] The System Memory Management Unit (SMMU), also known as the Input-Output Memory Management Unit (IOMMU), is a hardware unit responsible for performing memory address translation and access permission checks for peripherals (such as DMA controllers, GPUs, and network interface cards). The main functions of the SMMU include memory isolation, address translation, and access control. Memory isolation restricts the memory accessible to a device to a specific, authorized region (preventing the device from accessing the entire physical memory). Address translation converts the I / O virtual address (IOVA) or device physical address (DMA address) used by the device into a host physical address (HPA), implementing address mapping, attribute conversion, and permission checks to achieve DMA address space isolation between different devices. The SMMU and the Memory Mapped Input / Output Page Table (MMIO) work closely together during device passthrough to complete a secure and efficient access control loop between the processor and the passthrough device, and between the device and memory. Specifically, the virtual machine can configure the device (setting IOVA, etc.) through the path controlled by the MMIO page table, and the SMMU translates and isolates DMA requests initiated by the device according to the configuration.

[0049] The Security Monitor Call (SMC) is a piece of firmware code running at the highest privilege level (EL3). It is the ultimate arbiter of the system's security state, responsible for switching between the Normal World (REE) and the Secure World (TEE).

[0050] Device passthrough (or direct device assignment) is a virtualization technology that allows virtual machines to directly and exclusively access physical hardware devices (such as graphics processors, network interface cards, and high-performance storage devices), bypassing the intervention of the virtual machine manager. The virtual machine manager is responsible for physically assigning devices to specific virtual machines and configuring the page tables of the SMMU / IOMMU so that the device can only access the memory region allocated to that virtual machine (using a mapping from IOVA to the GPA and then to the HPA of the virtual machine's memory).

[0051] PCIe Access Control Services (ACS) are a set of optional features in the PCIe bus standard designed to enhance security and isolation in PCIe topologies, particularly important for enabling device passthrough in virtualized environments. ACS can perform source verification and access control on transfers initiated by downstream devices, preventing one PCIe device from maliciously or erroneously interfering with another device or accessing unauthorized memory regions, thus enhancing the security and reliability of device passthrough.

[0052] Exemplary methods

[0053] This specification provides a secure boot method applied to a computing device, the computing device including: a processor and a system memory management unit, the processor including a first register, such as... Figure 3 As shown, the secure boot method includes:

[0054] S301: In response to the startup operation, execute the startup process;

[0055] The startup process includes:

[0056] S3011: When the value of the first register indicates that the device passthrough function of the processor is enabled, import the target driver of the processor and write the import result of the target driver into a measurement file; the measurement file is used to characterize the enabled state of the device passthrough function of the processor and the security state of the computing device; the target driver is the driver of the device passthrough function of the processor.

[0057] S3012: Transfer the control authority of the system memory management unit from the insecure virtual machine manager to the secure virtual machine manager;

[0058] S3013: If the metric file verification is successful, a device pass-through request for the target device is received from the user, and the target device mounted on the ordinary virtual machine is transferred to the secure virtual machine; the insecure virtual machine manager and the ordinary virtual machine run in the rich execution environment subsystem, the secure virtual machine manager and the secure virtual machine run in the trusted execution environment subsystem, and the rich execution environment subsystem and the trusted execution environment subsystem are implemented based on the processor.

[0059] In this embodiment, as described above, the secure boot method can achieve secure verification of the device passthrough environment during the boot process without dedicated security hardware, ensuring that the virtual machine and the target device can perform device passthrough access in a secure environment. Specifically, in order to ensure the security of the device passthrough function boot process without dedicated security hardware, thereby reducing the hardware and communication complexity of the computing device, this specification provides a secure boot method. This method is applied to a computing device including a processor and a system memory management unit. During the startup process of the computing device, the value of the processor's first register indicates whether the processor's device passthrough function is enabled. If the value of the first register indicates that the processor's device passthrough function is enabled, the processor's target driver is imported, and the import result of the target driver is written to a measurement file. Then, the control authority of the system memory management unit is transferred from the insecure virtual machine manager to the secure virtual machine manager. Finally, if the measurement file verification is successful, a user's device passthrough request for the target device is received, and the target device mounted on the ordinary virtual machine is transferred to the secure virtual machine. In this way, the user can use the secure virtual machine to passthrough access the target device. In the above process, a trusted execution environment subsystem is implemented based on the processor. During the startup process, the control authority of the system memory management unit and the target device are transferred from the ordinary execution environment to the trusted execution environment (that is, the control authority of the system memory management unit is transferred to the secure virtual machine manager, and the target device is transferred to the secure virtual machine). In this way, in the absence of dedicated security hardware (such as a secure coprocessor (SOP)), the trusted execution environment subsystem implemented based on the processor can ensure the secure startup of the processor's device passthrough function. On the basis of ensuring the secure and reliable startup of the device passthrough function, the hardware requirements of the computing device are reduced.

[0060] In addition, during secure boot, the system memory management unit can follow the traditional initialization process. That is, the non-secure virtual machine manager in the Rich Execution Environment (REE) subsystem can boot and initialize the system memory management unit. After initialization, the control of the system memory management unit is transferred to the secure virtual machine manager in the Trusted Execution Environment (TEE) subsystem. In this way, there is no need to load and boot the system memory management unit driver in the Trusted Execution Environment, which helps to simplify the processing logic of the Trusted Execution Environment subsystem, reduce the algorithm burden of the Trusted Execution Environment subsystem, and reduce the hardware requirements of the Trusted Execution Environment subsystem.

[0061] Similarly, during the startup process, the target device (i.e., the peripheral device that requires device passthrough) can first be mounted under a regular virtual machine in the Trusted Execution Environment (TEE) subsystem. Then, the insecure virtual machine manager transfers the target device mounted under the regular virtual machine to the secure virtual machine, thus enabling the target device to be mounted under the secure virtual machine. In this way, there is no need to make complex adjustments to the relevant drivers of the secure virtual machine in the TEE subsystem, nor is there a need to add target device initialization and other related logic to the relevant drivers of the secure virtual machine. This helps to simplify the processing logic of the TEE subsystem, reduce the algorithm burden of the TEE subsystem, and reduce the hardware requirements of the TEE subsystem.

[0062] To meet the configuration requirements of the first register in different scenarios, in one implementation, the configuration process of the first register includes:

[0063] During the secure boot process, the target firmware configures the value of the first register to a target value; the target firmware includes trusted firmware.

[0064] or;

[0065] When the computing device includes a backplane management controller, the number of processors is at least one. Before the processors are started, the backplane management controller writes configuration information containing the target value into the first register of at least one of the processors through a target channel, based on the configuration information of the server configuration file.

[0066] When the computing device includes a backplane management controller, the backplane management controller can configure the value of the first register through out-of-band configuration. The computing device may include at least one processor; this scenario can be a server scenario. The backplane management controller can manage the first register of at least one processor, improving the configuration efficiency of the first register. In this scenario, a dedicated target channel can be established between the backplane management controller and the processor. This target channel can be a secure channel encrypted with a key. Furthermore, this target channel can only transmit configuration information, reducing the risk of leakage of target information.

[0067] In addition to the configuration methods described above, an in-band configuration method can also be provided, whereby the target firmware configures the value of the first register during the secure boot process of the processor. The target firmware may include trusted firmware with register initialization or configuration functions. For example, in one embodiment, the target firmware may include BL31 firmware or BL32 firmware. This specification does not limit this, and the specific choice depends on the actual situation.

[0068] In one implementation, a feasible process is provided for transferring a target device from a regular virtual machine to a secure virtual machine, such as... Figure 4 As shown, it specifically includes:

[0069] The insecure virtual machine manager initiates a device donation request carrying base address register information to the secure virtual machine manager; the base address register information is used to describe the target device.

[0070] The secure virtual machine manager discovers the target device based on the base address register information and mounts the target device onto the secure virtual machine.

[0071] The Base Address Register (BAR) is a set of special registers within a target device. It defines the mapping range of the device within the system address space (which may include memory or I / O address space), serving as the base address identifier during data interaction. The BAR can also be used to externally announce information such as the size and type of the address space required by the target device. In some implementations, the BAR information includes the base address and length of the register. The base address can be assigned by the system during device initialization and can be a physical base address (memory or I / O address). The target device can be discovered on the bus using the BAR information, and subsequent data interaction and access processes can be completed based on this information.

[0072] In this embodiment, the target device is first mounted under a non-secure virtual machine manager, and then the non-secure virtual machine manager transfers the target device to the secure world by initiating a device donation request carrying base address register information. This avoids the process of the secure world loading complex drivers and handling device initialization, and reduces the resource requirements of the secure world.

[0073] exist Figure 4 In this context, when a target device is mounted to a non-secure virtual machine manager, it is represented as a Device, and this mounting state can be called insecure mounting. The non-secure virtual machine manager can donate the target device to the secure virtual machine manager through device donation; in this case, the target device is represented as a Secure Device. Secure access between the non-secure and secure virtual machine managers can be achieved through shared memory or SMC calls.

[0074] To ensure security and isolation between devices during direct access and prevent situations such as the target device accessing other devices, in one embodiment, the secure virtual machine manager discovers the target device based on the base address register information and mounts the target device to the secure virtual machine, further comprising:

[0075] The PCIe controller corresponding to the secure virtual machine enables PCIe access control services.

[0076] The PCIe controller's PCIe Access Control Services (ACS) prevent unauthorized access, isolate communication between peer devices, and enhance security in virtualized environments. Specifically, the PCIe controller checks the Requester ID of the Transaction Layer Packet (TLP) to determine that only requests from legitimate sources can access the target resource, preventing devices from accessing unauthorized memory areas via DMA and thus preventing data leaks. The PCIe protocol allows peer-to-peer (P2P) transmission, meaning different Endpoint (EP) devices connected under the same PCIe switch can communicate with each other without going through the root complex (RC) device. The PCIe controller can control this direct communication or determine whether a TLP is routed normally, blocked, or redirected, thereby avoiding improper packet routing.

[0077] One embodiment of this specification also provides a feasible transfer process for control authority of a system memory management unit, specifically, see reference [link to documentation]. Figure 5 (exist Figure 5 In this context, the System Memory Management Unit (SMMU) is used. The transfer of control of the System Memory Management Unit from the insecure virtual machine manager to the secure virtual machine manager includes:

[0078] The security monitor instructs the insecure virtual machine manager to save the runtime context of the system memory management unit;

[0079] The security monitor modifies the permission control register of the system memory management unit to cancel the non-secure virtual machine manager's control permissions over the system memory management unit and add the secure virtual machine manager's control permissions over the system memory management unit.

[0080] The security monitor notifies the security virtual machine manager to take over the system memory management unit, instructing the security virtual machine manager to verify the security of the saved runtime context. After successful verification, the security virtual machine manager controls the system memory management unit to restart based on the runtime context.

[0081] In this embodiment, a non-secure virtual machine manager can import the driver for the system memory management unit (MMU) to gain management privileges over the MMU. The driver import process can include loading, resolving, and initializing. Loading refers to reading the driver's binary file from storage into memory and allocating a dedicated memory area for storage. Resolving refers to performing validity checks on the driver (such as signature verification to ensure the signature has not been tampered with) and resolving its dependencies (such as kernel functions the driver needs to call and other dependent modules). Initializing refers to executing the driver's initialization function to complete hardware resource binding (such as associating the driver with the hardware address of the MMU), register configuration (such as setting interrupt vectors), and data structure initialization (such as creating an address mapping table cache).

[0082] Therefore, it can be seen that by first obtaining control of the system memory management unit from the non-secure virtual machine manager and then transferring control of the system memory management unit to the secure virtual machine manager, it is not necessary to write the relevant logic for performing the above operations into the secure virtual machine manager driver, nor is it necessary for the trusted execution environment subsystem or the secure virtual machine manager to perform complex driver import operations. This helps to simplify the operation logic of the secure world and reduce the performance requirements of the secure world.

[0083] When it is necessary to transfer control of the System Memory Management Unit to the Secure Virtual Machine Manager, the Security Monitor instructs the Insecure Virtual Machine Manager to save the System Memory Management Unit's runtime context. This runtime context may include active address mapping tables, device permission configurations, and interrupt statuses. The runtime context may be saved in shared memory, which can serve as a communication medium between the Rich Execution Environment (REME) subsystem and the Trusted Execution Environment (TEE) subsystem.

[0084] Afterwards, the security monitor modifies the permission control register of the system memory management unit to transfer control permissions from the insecure virtual machine manager to the secure virtual machine manager. Finally, it notifies the secure virtual machine manager to take over the system memory management unit, thus completing the transfer of the system memory management unit from the insecure side to the secure side.

[0085] After the metric file verification is successful and the target device is mounted under the secure virtual machine, the secure virtual machine can perform direct access to the target device. Specifically, the secure boot method further includes:

[0086] The secure virtual machine creates an access event queue and / or a memory-mapped input / output page table. The access event queue is used to store queue information of the secure virtual machine's access requests to the target device, and the memory-mapped input / output page table is used to map the registers of the target device to the physical memory address space of the processor.

[0087] The secure virtual machine performs DMA access to the target device based on the access event queue, and / or the secure virtual machine performs data read operations on the target device based on the memory-mapped input / output page table.

[0088] This embodiment provides two methods for the secure virtual machine to directly access the target device. The first method is to perform DMA access to the target device through an access event queue, which supports data transfer operations by the secure virtual machine. The second method is to use memory-mapped input / output page tables, which supports data viewing operations by the secure virtual machine on the target device, meeting the target device's need for quick access to specific data.

[0089] To prevent the secure virtual machine from accessing unauthorized areas during pass-through access to the target peripheral, in one embodiment, the secure virtual machine performs data reading operations on the target device based on the memory-mapped input / output page table, including:

[0090] The secure virtual machine verifies the access granularity of the data read / write operation based on a pre-set security page. The verification passes when the access granularity is an integer multiple of the minimum granularity of secure memory, and the data read / write operation is executed. The security page is the memory page set by the secure virtual machine based on the minimum granularity of secure memory set by the secure virtual machine manager. If the secure virtual machine manager corresponding to the secure virtual machine has memory encryption enabled, the data targeted by the data read / write operation is represented in plaintext.

[0091] The secure virtual machine performs DMA access to the target device based on the access event queue, including:

[0092] Write the DMA request for the target device into the access event queue;

[0093] The DMA controller reads the DMA request from the access event queue and performs the DMA operation according to the DMA request and the address mapping relationship stored in the system memory management unit.

[0094] In this embodiment, the minimum granularity of secure memory can be the smallest unit of memory allocation or access set by the secure virtual machine manager (e.g., 4KB), ensuring fine-grained memory isolation. When the secure virtual machine performs data read operations on the target device based on the memory-mapped input / output page table, it verifies the access granularity of the data read operation based on the pre-set secure page, restricting the access granularity to an integer multiple of the minimum granularity of secure memory, thus preventing unauthorized access to small-granularity memory regions.

[0095] Furthermore, in some cases, if the secure virtual machine manager has memory encryption enabled by default, in this embodiment, all interactive data when accessing the target device is displayed in plaintext, thus eliminating the need for data encryption and improving data interaction efficiency. This is because, in this embodiment, data security during device pass-through can be guaranteed by the secure boot process based on the trusted execution environment subsystem described above, thereby omitting the data encryption process during device pass-through and improving data interaction efficiency.

[0096] In some implementations, a fault handling method for the startup process is also provided. Specifically, the secure startup method further includes:

[0097] Upon receiving a user's security verification request, the system parses the security verification request, generates a verification report based on the parsing result and the measurement file, and returns the verification report to the user.

[0098] If the verification report is not verified by the user, then the device pass-through function of the processor will be stopped.

[0099] If the PCIe controller corresponding to the secure virtual machine cannot enable the PCIe access control service, then the secure virtual machine's device pass-through access to the target device will be denied.

[0100] This implementation provides fault handling logic for each stage of the startup process. A security verification request is a user's request for the computing device to verify its security. After parsing the security verification request, a verification report can be generated based on the parsing results and measurement files, and returned to the user. After the user reviews the verification report and verifies the computing device's security, they can instruct the computing device to continue initiating the processor's device passthrough function; if the verification report fails verification, the computing device can be instructed to stop initiating the processor's device passthrough function to prevent unexpected activation. Furthermore, if the PCIe controller corresponding to the secure virtual machine cannot enable PCIe access control services, there is a risk of cross-access between target devices mounted on the secure virtual machine. Therefore, in this case, device passthrough access from the secure virtual machine to the target devices can be denied to ensure the security of device data.

[0101] After describing the startup process and the device pass-through access process, one embodiment of this specification also proposes a method for managing the lifecycle of device pass-through peripherals without dedicated security hardware. Specifically, refer to... Figure 6 One embodiment of this specification provides a management method for device pass-through to peripherals, applied to a computing device, the computing device including a processor, the processor being used to construct a rich execution environment subsystem and a trusted execution environment subsystem, the management method for device pass-through to peripherals including:

[0102] S601: The secure virtual machine manager receives a device donation request for a target device initiated by the insecure virtual machine manager. Based on the device donation request, the secure virtual machine manager mounts the target device to the secure virtual machine manager and marks the target device as a first state. The first state indicates that the target device is in an insecure state and awaits allocation to a secure virtual machine. Both the secure virtual machine manager and the secure virtual machine run in the trusted execution environment subsystem, and the insecure virtual machine manager runs in the rich execution environment subsystem.

[0103] S602: After the security virtual machine manager sets the configuration permission of the registers of the target device to be configurable by the trusted execution environment subsystem, the security virtual machine manager changes the target device from the first state to the second state. The second state indicates that the target device is in a secure state but has not been assigned to the security virtual machine.

[0104] S603: After receiving the pass-through mount request from the security virtual machine for the target device, the security virtual machine manager passes-through mounts the target device in the second state to the security virtual machine, and modifies the configured target device from the second state to the third state. The third state indicates that the target device is in a secure state and has been assigned to the security virtual machine.

[0105] In this embodiment, as described above, the target device can first be mounted on a non-secure virtual machine manager, and then the non-secure virtual machine manager initiates a device donation request to the secure virtual machine manager. In this way, the secure virtual machine manager does not need to perform operations such as importing the target device driver, which helps reduce the complexity of the algorithmic logic required by the secure world when the target device is mounted on the secure virtual machine manager. Furthermore, based on the trusted environment provided by the trusted execution environment subsystem to ensure the security of the device's direct connection to peripherals, the performance requirements of the trusted execution environment subsystem are reduced.

[0106] The registers of the target device are the core interface for interaction between the virtual machine / processor and the device. These registers can be used to control device behavior, transfer data, and provide status feedback. In some implementations, the registers of the target device may include configuration space registers and device function registers, etc. The configuration space registers may include device identification registers, base address registers, status and control registers, and interrupt-related registers, etc.; the device function registers may include control registers, status registers, and data buffer registers, etc. This specification does not limit the specific registers; the choice depends on the actual situation.

[0107] Device pass-through peripherals refer to devices that can be accessed via device pass-through. For example, after a target device is mounted to a secure virtual machine, the target device can be called a device pass-through peripheral of the secure virtual machine. This implementation provides a state management method for target devices during the mounting process. By marking the first to third states, the current state of the target device can be clearly identified, allowing the secure virtual machine manager to better manage each target device based on its current state. For example, when the target device is in the first state, the secure virtual machine manager can determine that the target device has been donated to the secure virtual machine manager by a non-secure virtual machine manager, but the secure virtual machine manager has not yet obtained configuration permissions for the target device's registers. When the target device is in the second state, the secure virtual machine manager can determine that the configuration permissions of the target device have been set to be configurable by the feasible execution environment subsystem, the current state is secure, it has not been assigned to a secure virtual machine, and it can be mounted to a secure virtual machine later. When the target device is in the third state, it indicates that the target device has been assigned to a specific secure virtual machine. At this time, the secure virtual machine can directly access the target device, and the target device cannot be assigned to other secure virtual machines. This avoids performing operations on the target device that are inconsistent with its current state, ensuring the security of the target device and the orderliness of its management.

[0108] In one embodiment, the management method for direct-to-peripheral device communication further includes:

[0109] Upon receiving an uninstallation request from the security virtual machine for the target device, the security virtual machine manager uninstalls the target device, which is in the third state, from the security virtual machine, clears the cache information of the security virtual machine, and changes the target device from the third state to the second state.

[0110] In this implementation, when it is necessary to uninstall the target device, the user can send an uninstallation request to the Security Virtual Machine Manager (SVM Manager), which manages the security virtual machine. The SVM Manager responds to the request, uninstalls the target device (currently in a third state) from the security virtual machine, clears the security virtual machine's cached information to reduce the risk of information leakage from the target device, and changes the target device from the third state to the second state to ensure that the target device can be reassigned. The security virtual machine's cached information can refer to multi-level cached information related to direct device access between the security virtual machine and the target device. This cached information may include temporary data, address mappings, or control commands during interaction between the security virtual machine and the target device. Failure to clear this cached information may lead to the leakage of relevant information about the target device, and may also result in residual cached information occupying the security virtual machine's storage resources.

[0111] In one implementation, before the secure virtual machine manager unloads the target device in the third state from the secure virtual machine, it further includes:

[0112] After the legality verification of the uninstallation request passes, the current state of the target device is checked. If the uninstallation requirements are met, the step of uninstalling the target device in the third state from the secure virtual machine is executed.

[0113] The unloading requirements include that the target device in the third state is currently in a normal state, and that there are no unfinished tasks in the target device.

[0114] In this embodiment, before uninstallation, the current status of the target device is checked to ensure that it is normal, that the security virtual machine is accessing the target device, and that there are any tasks being executed on the target device. The uninstallation steps are then performed only after the current status of the target device meets the uninstallation requirements to avoid abnormal status caused by device uninstallation.

[0115] In one embodiment, the management method for direct-to-peripheral device communication further includes:

[0116] After the non-secure virtual machine manager completes the mounting of the target device to the non-secure virtual machine manager, it sends a device donation request carrying the base address register information of the target device to the secure virtual machine manager; the base address register information is used to describe the target device.

[0117] The step of mounting the target device to the secure virtual machine manager based on the device donation request includes:

[0118] The secure virtual machine manager discovers the target device based on the base address register information and mounts the target device to the secure virtual machine manager.

[0119] This embodiment provides a feasible process for temporarily mounting a target device by a non-secure virtual machine manager and then donating the target device to a secure virtual machine manager. After discovering the target device based on its base address register information, the secure virtual machine manager first mounts the target device to itself. Once it obtains register configuration permissions for the target device, it then formally mounts it to the secure virtual machine. For details regarding base address register information, please refer to the preceding descriptions.

[0120] In one implementation, the secure virtual machine manager discovers the target device based on the base address register information and attaches the target device to the secure virtual machine, further comprising:

[0121] The PCIe controller corresponding to the secure virtual machine enables PCIe access control services.

[0122] For information on PCIe access control services, please refer to the relevant description above. In this embodiment, by enabling PCIe access control services, unauthorized access operations by secure virtual machines can be prevented.

[0123] Optionally, the target device includes at least one of a graphics processor, a neural network processor, and a network interface card.

[0124] Accordingly, this specification also provides a method for managing device pass-through peripherals during the device pass-through function startup and target device mounting process in the absence of dedicated security hardware. This method focuses on the control and management of the PCIe controller and related hardware and software during the aforementioned process. Specifically, refer to... Figure 7 The device pass-through peripheral management method is applied to a computing device, which includes a processor and an RC device. The processor is used to build a trusted execution environment subsystem, and the RC device includes a PCIe controller and configuration registers. The device pass-through peripheral management method includes:

[0125] S701: During the secure boot process, the target firmware reads the value of the configuration register. When the value of the configuration register indicates that the device pass-through function is enabled, the device pass-through driver is imported. The device pass-through driver is the driver for the device pass-through function. The target firmware includes trusted firmware.

[0126] S702: In response to the first request to pass through and mount the target device, the target firmware sends a second request to the security virtual machine manager. The second request is used to instruct the security virtual machine manager to configure the PCIe controller mounting the target device to a secure state, and to instruct the security virtual machine manager to mount the target device under the root node of the RC device after unmounting the peripheral currently mounted on the PCIe controller and after the security verification of the target device is passed. The PCIe controller in the secure state rejects the mounting of non-secure peripherals, and the security virtual machine manager runs in the trusted execution environment subsystem.

[0127] refer to Figure 8 , Figure 8 A schematic diagram of a feasible system architecture for a PCIe system is shown. The PCIe system may include a processor (CPU), RC (Root Complex) devices, EP (Endpoint) devices, and switch devices. The RC device may be located inside the processor or in a chipset closely adjacent to the processor. The RC device serves as the interface between the processor and the PCIe topology. The RC device may include one or more PCIe ports, which can directly connect to EP devices or connect to switch devices to expand the number of devices. The switch device can be used to expand the number of PCIe ports; a switch device can expand the number of EP devices by adding PCIe ports from one RC device. EP devices are functional devices that perform specific functions. In this specification, the target device exists and is used as an EP device after being mounted. In some embodiments, the RC device may include one or more PCIe controllers. The PCIe controller may be a hardware logic block responsible for implementing all or part of the low-level details of the physical layer, data link layer, and transaction layer of the PCIe protocol stack.

[0128] The Secure Boot process can include step-by-step verification of trusted firmware to establish a complete chain of trust. During this process, the target firmware reads the values ​​of its configuration registers to determine whether to import the device pass-through driver for the RC device. The target firmware can include at least one of the trusted firmwares; for ARM chips, as mentioned earlier, trusted firmware can include BL1, BL2, BL31, and BL32 firmware, etc. During the boot process, after a trusted firmware has passed verification and completed boot loading, it can read the values ​​of its configuration registers. For example, in some implementations, the target firmware includes BL32 firmware. After BL32 firmware has completed boot loading, it can read the values ​​of its configuration registers and determine whether to import the device pass-through driver for the RC device based on these values. Thus, the process of importing the device pass-through driver is integrated into the Secure Boot process, and the security of importing the device pass-through driver is ensured by leveraging the chain of trust established through step-by-step verification during Secure Boot.

[0129] Device passthrough driver refers to the driver in the processor related to the device passthrough function. The process of importing the device passthrough driver can be referred to the relevant description above, and will not be repeated here.

[0130] After the device passthrough driver is imported, the user can initiate a first request to passthrough a target device. The target firmware then sends a second request to the Secure Virtual Machine Manager (SVM), instructing the SVM to configure the PCIe controller of the target device to a secure state. In some implementations, the SVM can configure the PCIe controller of the target device to a secure state based on the Trusted Execution Environment (TEE) subsystem. The purpose of configuring the PCIe controller to a secure state is to ensure that only the trusted Secure World can access and configure the PCIe controller and the devices mounted on it, while the operating system or software in the Normal World cannot access it, thus preventing malicious or erroneous operations on critical hardware resources. The process of configuring the PCIe controller to a secure state may include: dividing memory into secure and insecure regions, configuring the security attributes of the target device registers and corresponding static memory, and configuring the corresponding page tables in the system memory management unit.

[0131] To prevent insecure peripherals from being mounted under a secure PCIe controller, the Secure Virtual Machine Manager instructs the PCIe controller to remove currently mounted peripherals. After these peripherals are unmounted and the target device passes security verification, the target device is mounted under the root node of the RC device. The PCIe controller in a secure state will then refuse to mount insecure peripherals, thus ensuring the security of the PCIe controller.

[0132] A secure peripheral device can refer to a target device whose security has been verified. In one implementation, a secure peripheral device list can be predefined, listing all trusted devices in the table. During implementation, if a target device is in the secure peripheral device list, it can be said to have passed security verification, and a target device that has passed security verification can be called a secure peripheral device; if it is not in the secure peripheral device list, it is said to have failed security verification.

[0133] In another implementation, the target device may carry a signature, and the security verification process may include signature verification. If the signature verification passes, the target device is said to have passed security verification and can be referred to as a secure peripheral device; if the signature verification fails, the target device is said to have failed security verification. This specification does not limit the feasible process of security verification; the specific process depends on the actual situation.

[0134] In this embodiment, the process of importing the device pass-through driver is integrated into the secure boot process. The trust chain established through step-by-step signature verification during secure boot ensures the security of the device pass-through driver import. The target firmware directly instructs the secure virtual machine manager to complete the secure state configuration of the PCIe controller and the secure mounting of the target device, thus ensuring the security of the device pass-through to peripherals.

[0135] In one embodiment, the management method for direct-to-peripheral device communication further includes:

[0136] After the device passthrough driver is imported, the device passthrough driver is measured, and the measurement results of the device passthrough driver are written into a measurement file. The measurement file is used to characterize the security status of the computing device.

[0137] After the target device is attached to the root node of the RC device, the attachment result is measured, and the measurement result is written to the measurement file.

[0138] In this embodiment, writing the mounting results into the measurement file allows the measurement file to more comprehensively characterize the security status of the computing device. Users can gain a comprehensive understanding of the security of the computing device and the device passthrough status from the measurement file.

[0139] In one embodiment, the management method for direct-to-peripheral device communication further includes:

[0140] Upon receiving a user's security verification request, the system parses the security verification request, generates a verification report based on the parsing result and the measurement file, and returns the verification report to the user.

[0141] For information on security certification, please refer to the relevant descriptions above.

[0142] In one embodiment, the management method for direct-to-peripheral device communication further includes:

[0143] When the PCIe controller receives an illegal mount request, it refuses to execute the illegal mount request and returns a first prompt message. The first prompt message is used to prompt the user that the PCIe controller refuses to mount the target device under a non-root node. The illegal mount request is used to request that the target device be mounted under a switching device connected to the RC device.

[0144] In this embodiment, after the PCIe controller is set to a secure state, it refuses to execute the illegal mount request, preventing attackers from using the switching device to perform device replacement and man-in-the-middle attacks. This ensures the validity of the measurement of the RC device during the secure boot process and guarantees security.

[0145] In one embodiment, the management method for direct-to-peripheral device communication further includes:

[0146] When the PCIe controller receives an illegal access request, it refuses to execute the illegal access request and returns a second prompt message. The second prompt message is used to inform the user that the PCIe controller refuses to execute an access request across the target device; the illegal access request includes an access request initiated by the target device to other devices.

[0147] In this embodiment, a PCIe controller in a secure state can reject access requests across target devices, thus ensuring the data security of the device.

[0148] In one embodiment, the management method for direct-to-peripheral device communication further includes:

[0149] If the PCIe controller is unable to enable the PCIe access control service, then the secure virtual machine's device pass-through access to the target device is denied.

[0150] In this embodiment, if the PCIe controller cannot enable the PCIe access control service, it can deny the secure virtual machine's device pass-through access to the target device to ensure data security.

[0151] In one embodiment, the target device includes at least one of a graphics processor, a neural network processor, and a network interface card (NIC).

[0152] Exemplary device

[0153] In one exemplary embodiment of this specification, a secure boot device is also provided, applied to a computing device, the computing device including a processor and a system memory management unit, the processor including a first register, the secure boot device including:

[0154] The first module is used to execute the startup process in response to the startup operation;

[0155] The startup process includes: when the value of the first register indicates that the device passthrough function of the processor is enabled, importing the target driver of the processor, and writing the import result of the target driver into a measurement file; the measurement file is used to characterize the enabled state of the device passthrough function of the processor and the security state of the computing device; the target driver is the driver for the device passthrough function of the processor.

[0156] The control authority of the system memory management unit is transferred from the insecure virtual machine manager to the secure virtual machine manager;

[0157] If the metric file verification is successful, a device passthrough request for the target device is received from the user, and the target device mounted on the ordinary virtual machine is transferred to the secure virtual machine; the insecure virtual machine manager and the ordinary virtual machine run in the rich execution environment subsystem, the secure virtual machine manager and the secure virtual machine run in the trusted execution environment subsystem, and the rich execution environment subsystem and the trusted execution environment subsystem are implemented based on the processor.

[0158] For specific limitations regarding the secure boot device, please refer to the limitations regarding the secure boot method above, which will not be repeated here. Each module in the aforementioned secure boot device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0159] In one exemplary embodiment of this specification, a device pass-through peripheral management device is also provided, applied to a computing device, the computing device including a processor, the processor being used to construct a rich execution environment subsystem and a trusted execution environment subsystem, the device pass-through peripheral management device including:

[0160] The second module: The secure virtual machine manager receives a device donation request for a target device initiated by the insecure virtual machine manager. Based on the device donation request, the secure virtual machine manager mounts the target device to the secure virtual machine manager and marks the target device as a first state. The first state indicates that the target device is in an insecure state and awaits allocation to a secure virtual machine. Both the secure virtual machine manager and the secure virtual machine run in the trusted execution environment subsystem, and the insecure virtual machine manager runs in the rich execution environment subsystem.

[0161] The third module: After the security virtual machine manager sets the configuration permissions of the registers of the target device to be configurable by the trusted execution environment subsystem, the security virtual machine manager changes the target device from the first state to the second state. The second state indicates that the target device is in a secure state but has not been assigned to the security virtual machine.

[0162] Fourth module: After receiving the pass-through mount request for the target device from the security virtual machine, the security virtual machine manager will pass-through mount the target device in the second state to the security virtual machine, and change the configured target device from the second state to the third state. The third state indicates that the target device is in a secure state and has been assigned to the security virtual machine.

[0163] Specific limitations regarding the management device for device pass-through to peripherals can be found in the limitations of the management method for device pass-through to peripherals above, and will not be repeated here. Each module in the aforementioned management device for device pass-through to peripherals can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0164] In one exemplary embodiment of this specification, a device pass-through peripheral management device is also provided, applied to a computing device, the computing device including a processor, the processor being used to construct a rich execution environment subsystem and a trusted execution environment subsystem, the device pass-through peripheral management device including:

[0165] Fifth module: During the secure boot process, the target firmware reads the value of the configuration register. When the value of the configuration register indicates that the device pass-through function is enabled, the device pass-through driver is imported. The device pass-through driver is the driver for the device pass-through function. The target firmware includes trusted firmware.

[0166] Module 6: In response to the first request to pass through and mount the target device, the target firmware sends a second request to the security virtual machine manager. The second request instructs the security virtual machine manager to configure the PCIe controller mounting the target device to a secure state, and to instruct the security virtual machine manager to mount the target device to the root node of the RC device after unmounting the peripheral currently mounted on the PCIe controller and after the security verification of the target device is passed. The PCIe controller in the secure state rejects the mounting of non-secure peripherals, and the security virtual machine manager runs in the trusted execution environment subsystem.

[0167] Specific limitations regarding the management device for device pass-through to peripherals can be found in the limitations of the management method for device pass-through to peripherals above, and will not be repeated here. Each module in the aforementioned management device for device pass-through to peripherals can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0168] Exemplary computing device

[0169] Another embodiment of this application also proposes a computing device, see [link to relevant documentation] Figure 9 As shown, an exemplary embodiment of this specification also provides a computing device, including: a memory, a processor, an RC device, and a system memory management unit, wherein the processor is configured to construct a trusted execution environment subsystem, the RC device includes a PCIe controller and a configuration register; the memory stores a computer program, and when the processor executes the computer program, it performs the steps of the secure boot method or the device pass-through peripheral management method described in the above embodiments of this specification according to various embodiments of this specification.

[0170] The internal structure of the computing device can be as follows: Figure 9 As shown, the computing device includes a processor, memory, network interface, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it follows the steps of the secure boot method or device pass-through peripheral management method according to various embodiments of this specification as described in the above embodiments.

[0171] The processor may include the main processor, as well as baseband chips, modems, etc.

[0172] It is understood that the processor in the embodiments of this specification can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this specification. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this specification can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0173] It is understood that the memory in the embodiments of this specification may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0174] Input devices may include devices that receive data and information input by the user, such as keyboards, mice, cameras, scanners, light pens, voice input devices, touch screens, pedometers, or gravity sensors.

[0175] Output devices may include devices that allow information to be output to the user, such as displays, printers, speakers, etc.

[0176] The communication interface may include any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0177] The computing device may also include a display component and a voice component. The display component may be a liquid crystal display screen or an e-ink display screen. The input device of the computing device may be a touch layer covering the display component, or a button, trackball or touchpad set on the casing of the computing device, or an external keyboard, touchpad or mouse, etc.

[0178] Those skilled in the art will understand that Figure 9 The structures shown are merely block diagrams of some structures related to the solutions in this specification and do not constitute a limitation on the computing devices on which the solutions in this specification are applied. Specific computing devices may include more or fewer components than those shown in the figures, or combine certain components, or have different component arrangements.

[0179] Exemplary computer program products and storage media

[0180] In addition to the methods and devices described above, the secure boot method provided in the embodiments of this specification can also be a computer program product, which includes computer program instructions that, when executed by a processor, cause the processor to perform the steps in the secure boot method or device pass-through peripheral management method described in the "Exemplary Methods" section above according to various embodiments of this specification.

[0181] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0182] The computer program product described herein can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments described herein. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0183] Furthermore, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor of the steps in the secure boot method or device pass-through peripheral management method according to various embodiments of this specification as described in the "Exemplary Methods" section above.

[0184] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this specification can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0185] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0186] The embodiments described above are merely illustrative of several implementation methods outlined in this specification. While the descriptions are specific and detailed, they should not be construed as limiting the scope of the solutions provided in this specification. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this specification, and these all fall within the scope of protection of this specification. Therefore, the scope of protection for this patent should be determined by the appended claims.

Claims

1. A management method for direct connection of a device to a peripheral device, characterized in that, Applied to computing devices, the computing devices include a processor and an RC device, the processor is used to build a trusted execution environment subsystem, and the RC device includes a PCIe controller and configuration registers. The management method for the device's direct-to-peripheral communication includes: During the secure boot process, the target firmware reads the value of the configuration register. When the value of the configuration register indicates that the device pass-through function is enabled, the device pass-through driver is imported. The device pass-through driver is the driver for the device pass-through function. The target firmware includes trusted firmware. In response to the first request to pass through and mount the target device, the target firmware sends a second request to the security virtual machine manager. The second request instructs the security virtual machine manager to configure the PCIe controller mounting the target device to a secure state, and to instruct the security virtual machine manager to mount the target device under the root node of the RC device after unmounting the peripheral currently mounted on the PCIe controller and after the security verification of the target device is passed. The PCIe controller in the secure state rejects the mounting of non-secure peripherals, and the security virtual machine manager runs in the trusted execution environment subsystem.

2. The method according to claim 1, characterized in that, Also includes: After the device passthrough driver is imported, the device passthrough driver is measured, and the measurement results of the device passthrough driver are written into a measurement file. The measurement file is used to characterize the security status of the computing device. After the target device is attached to the root node of the RC device, the attachment result is measured, and the measurement result is written to the measurement file.

3. The method according to claim 2, characterized in that, Also includes: Upon receiving a user's security verification request, the system parses the security verification request, generates a verification report based on the parsing result and the measurement file, and returns the verification report to the user.

4. The method according to claim 1, characterized in that, Also includes: When the PCIe controller receives an illegal mount request, it refuses to execute the illegal mount request and returns a first prompt message. The first prompt message is used to prompt the user that the PCIe controller refuses to mount the target device under a non-root node. The illegal mount request is used to request that the target device be mounted under a switching device connected to the RC device.

5. The method according to claim 1, characterized in that, Also includes: When the PCIe controller receives an illegal access request, it refuses to execute the illegal access request and returns a second prompt message. The second prompt message is used to inform the user that the PCIe controller refuses to execute an access request across the target device; the illegal access request includes an access request initiated by the target device to other devices.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: If the PCIe controller is unable to enable the PCIe access control service, then the secure virtual machine's device pass-through access to the target device is denied.

7. The method according to any one of claims 1 to 5, characterized in that, The target device includes at least one of a graphics processor, a neural network processor, and a network interface card (NIC).

8. The method according to any one of claims 1 to 5, characterized in that, The target firmware includes BL32 firmware.

9. A computing device, characterized in that, include: A processor and an RC device, the processor being used to construct a trusted execution environment subsystem, the RC device including a PCIe controller and a configuration register; wherein the processor is configured to execute the device pass-through peripheral management method according to any one of claims 1 to 8.

10. A computer program product, characterized in that, The computer program product includes a computer program, which, when executed by a processor, implements the device pass-through peripheral management method as described in any one of claims 1 to 9.

Images