Access control method, IOMMU, chip, access control system and computer equipment

Abstract

The embodiment of the invention provides an access control method, an IOMMU, a chip, an access control system and computer device.The method is applied to the IOMMU and comprises the steps that an access request of a peripheral is obtained, and the access request carries an IO virtual address and BDF information of the peripheral; according to the BDF information of the peripheral, the device identity of the peripheral is confirmed, and the device identity of the peripheral is divided into a TEEIO device and a non-TEEIO device; performing address conversion processing on the IO virtual address to obtain a corresponding HPA; if the peripheral is a non-TEEIO device, judging whether the HPA belongs to the MMIO address range of the TEEIO device or not; if the HPA belongs to the MMIO address range of the TEEIO equipment, refusing to execute the access request; and if the HPA does not belong to the MMIO address range of the TEEIO equipment, continuing to execute the access request. According to the embodiment of the invention, the risk that non-TEEIO equipment steals the data of the MMIO space of the TEEIO equipment can be eliminated, and the data security is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to an access control method, an IOMMU, a chip, an access control system, and a computer device. Background Technology

[0002] An encrypted virtual machine (VM) is a type of virtual machine that uses secure virtualization technology. Specifically, an VM is a VM instance built on top of secure virtualization technology, and its memory space is encrypted to prevent unauthorized access by the host or other VMs. Building upon this, TEEIO (Trusted Execution Environment Input / Output) is a trusted peripheral access mechanism for encrypted VMs. It allows peripherals such as deep learning units and data acceleration units to directly and securely serve the encrypted VM within the virtualization environment. Specifically, deep learning units, data acceleration units, and other peripherals are included within the TEE (Trusted Execution Environment) as TEEIO devices and directly connected to the encrypted VM, thus allowing TEEIO devices to access the VM's memory space.

[0003] However, non-TEEIO devices may still exist in computer systems that are not included in the TEE scope. These non-TEEIO devices may attempt to steal or interfere with the MMIO (Memory Mapped Input / Output) space of TEEIO devices through end-to-end (E2E) bypass paths, posing a potential risk of data leakage. Therefore, how to provide technical solutions to eliminate the risk of non-TEEIO devices stealing data from the MMIO space of TEEIO devices and improve data security has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of this application provide an access control method, an IOMMU, a chip, an access control system, and a computer device to eliminate the risk of non-TEEIO devices stealing data from the MMIO space of TEEIO devices and improve data security.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions.

[0006] In a first aspect, embodiments of this application provide an access control method applied to an IOMMU, the method comprising: Obtain an access request from a peripheral device, the access request carrying an I / O virtual address and the BDF information of the peripheral device; Based on the peripheral's BDF information, confirm the peripheral's device identity. The peripheral's device identity is divided into TEEIO devices and non-TEEIO devices. For the I / O virtual address, perform address translation processing to obtain the corresponding HPA; If the peripheral device is not a TEEIO device, determine whether the HPA belongs to the MMIO address range of the TEEIO device. If the HPA belongs to the MMIO address range of the TEEIO device, the access request is denied. If the HPA is not within the MMIO address range of the TEEIO device, continue to execute the access request.

[0007] Secondly, embodiments of this application provide an IOMMU, including: The TEEIO verification module is used to confirm the device identity of a peripheral based on the peripheral's BDF information when the IOMMU obtains an access request from the peripheral. The device identity of the peripheral is divided into TEEIO devices and non-TEEIO devices. The access request carries the IO virtual address and the peripheral's BDF information. The DMA remapping module is used to perform address translation processing on the I / O virtual address to obtain the corresponding HPA; The MMIO access control module is used to determine whether the HPA belongs to the MMIO address range of the TEEIO device if the peripheral device is not a TEEIO device. If the HPA belongs to the MMIO address range of the TEEIO device, the access request is rejected. If the HPA does not belong to the MMIO address range of the TEEIO device, the access request is executed.

[0008] Thirdly, embodiments of this application provide an access control system, including: As described in the second aspect above, IOMMU; The memory's I / O page tables are divided into ordinary IOPTs and secure IOPTs; ordinary IOPTs are address mapping tables used by ordinary peripherals and configured by the operating system or hypervisor; secure IOPTs are address mapping tables used by TEEIO devices and configured and managed by the security processor. TEEIO devices, trusted peripherals bound to encrypted virtual machines, are included in the TEE scope and can be directly connected to encrypted virtual machines for use; Non-TEEIO devices are not included in the TEE scope.

[0009] Fourthly, embodiments of this application provide a chip including the IOMMU as described in the second aspect above.

[0010] Fifthly, an embodiment of this application provides a computer device including the chip described in the fourth aspect above, or the access control system described in the third aspect above.

[0011] In the access control method provided in this application embodiment, after obtaining an access request, the IOMMU can confirm the device identity of the peripheral based on the BDF information of the peripheral carried in the access request. The device identity of the peripheral is divided into TEEIO devices and non-TEEIO devices. If the device identity of the peripheral is a non-TEEIO device, after performing address translation processing on the IO virtual address carried in the access request to obtain the corresponding HPA, further address post-verification of the HPA is performed to determine whether the HPA belongs to the MMIO address range of the TEEIO device. If so, it indicates that the non-TEEIO device is accessing the MMIO space of the TEEIO device, thereby rejecting the access request. If not, the access request continues to be executed.

[0012] As can be seen, the access control method provided in this application effectively blocks unauthorized access to the MMIO space of a TEEIO device by introducing peripheral identification and address post-verification within the IOMMU. Specifically, when a system configuration error occurs and the MMIO space of a TEEIO device is incorrectly mapped into the IO page table corresponding to a non-TEEIO device, the non-TEEIO device may mistakenly enter the protected MMIO space of the TEEIO device. Alternatively, an attacker may intentionally bypass the traditional permission mechanism to access the MMIO space of a TEEIO device by constructing the IO virtual address of the access request from the non-TEEIO device and by tampering with the IO page table. To avoid the aforementioned situation where non-TEEIO devices access the MMIO space of a TEEIO device unauthorizedly, this application introduces a dual protection mechanism of peripheral identification and HPA address verification in the IOMMU. Even if an attacker controls the contents of the IO page table, they cannot access the MMIO space of the TEEIO device unauthorizedly, thereby eliminating the risk of non-TEEIO devices stealing data from the MMIO space of the TEEIO device. This achieves hardware-level isolation of the relevant control paths of the encrypted virtual machine, significantly improving data security and control security. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram of the system architecture for secure virtualization technology.

[0015] Figure 2 This is an example diagram of peripherals communicating via a P2P channel in a PCIe architecture.

[0016] Figure 3 This is an example diagram of E2E access for peripherals in the PCIe architecture.

[0017] Figure 4 This is an example diagram of the communication architecture between an encrypted virtual machine and peripherals based on a SOC.

[0018] Figure 5 An example diagram of an access control system provided in an embodiment of this application.

[0019] Figure 6 A flowchart of the access control method provided in the embodiments of this application. Detailed Implementation

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

[0021] In secure virtualization technology, an encrypted virtual machine (VM) refers to a VM whose data in its memory space is encrypted and protected. Specifically, each encrypted VM is assigned a unique ASID (Address Space Identifier) ​​by the OS (Operating System) upon startup. Simultaneously, the PSP (Platform Security Processor) generates a unique VM key for the encrypted VM (the VM key is used for encryption and decryption of data in the VM's memory space). The VM's ASID and VM key are bound and stored in the UMC (Unified Memory Controller). When an encrypted VM accesses memory, the GPA (Guest Physical Address) is converted to HPA (Host Physical Address) via NPT (Nested Page Table). The HPA carries the encrypted VM's ASID and an encryption flag (Cbit). The UMC uses the encryption flag to determine whether encryption protection is required for this memory access. If encryption protection is required, the VM key bound to the ASID carried by the HPA is used for data encryption and decryption. By using the data encryption and decryption mechanism of the virtual machine memory space of the encrypted virtual machine, the host (i.e., the physical host) can be blocked from accessing the virtual machine memory space of the encrypted virtual machine, effectively preventing the host from stealing or tampering with the data of the encrypted virtual machine and improving the data security of the encrypted virtual machine.

[0022] For ease of understanding, Figure 1 An exemplary diagram of a system architecture for secure virtualization technology is shown, such as... Figure 1 As shown, the system architecture may include: CPU (Central Processing Unit) 110, memory controller 120 (memory controller such as UMC), memory 130, and security processor 140; Among them, CPU 110 can be configured with a virtual machine manager through software to create one or more virtual machines. The created virtual machines can be managed by the virtual machine manager. For example, the virtual machine manager can manage the virtual machine memory space of the virtual machine in memory 130. Part or all of the space of memory 130 can be used as the virtual machine memory space allocated to the virtual machine. The memory controller 120 is hardware that controls the memory 130 and enables data exchange between the memory 130 and the CPU 110. The security processor 140 is a dedicated processor for secure virtual machine data security in secure virtualization technology. In secure virtualization technology, the security processor 140 can assign different virtual machine keys to different encrypted virtual machines and store the virtual machine keys of the encrypted virtual machines in the memory controller 120. In specific implementation, different encrypted virtual machines can have different ASIDs. The virtual machine key assigned by the security processor 140 to the encrypted virtual machine can be bound to the virtual machine's ASID. Thus, the memory controller 120 can perform data encryption and decryption on the virtual machine memory space of the encrypted virtual machine based on the virtual machine key bound to the encrypted virtual machine's ASID, so as to achieve data security isolation between the encrypted virtual machine and the host operating system, as well as between different encrypted virtual machines. In other words, a virtual machine that has been assigned a virtual machine key is an encrypted virtual machine. Correspondingly, the virtual machine memory space of an encrypted virtual machine is an encrypted memory space, and the memory pages in the encrypted memory space are encrypted memory pages, with their data protected by encryption. On the other hand, a virtual machine that has not been assigned a virtual machine key is a normal virtual machine. The virtual machine memory space of a normal virtual machine is a normal memory space, and the memory pages in the normal memory space are normal memory pages, with their data not protected by encryption. Furthermore, whether a memory page in memory is an encrypted memory page can be distinguished by the value of the encryption flag bit (C bit). For example, when the encryption flag bit is the first value (e.g., 1), it indicates that the corresponding memory page is an encrypted memory page, while when the encryption flag bit is the zeroth value (e.g., 0), it indicates that the corresponding memory page is a normal memory page.

[0023] Based on the above explanation, the operating principle of secure virtualization technology can be summarized as follows: When an encrypted virtual machine (VM) starts, the security processor assigns a VM key to the VM and binds the VM key to the VM's ASID. When there are read / write operations on memory pages, if the C bit corresponding to the memory page is 1, it indicates that the memory page is an encrypted memory page. The memory controller uses the VM key bound to the ASID to read / write data on the memory page. If the C bit is 0, it indicates that the memory page is a normal memory page, and the memory controller reads / writes data on the memory page in plaintext. Therefore, in secure virtualization technology, because the VM key of the encrypted VM is managed by the security processor, the host operating system cannot obtain the VM key. Thus, the data read by the host operating system from the encrypted memory space is in ciphertext form, which greatly improves the data security of the encrypted VM. Furthermore, each encrypted VM has a unique ASID upon startup. The security processor creates different VM keys for encrypted VMs with different ASIDs, preventing encrypted VMs from reading each other's data and achieving data isolation between encrypted VMs, thereby enhancing their data security.

[0024] In secure virtualization scenarios, encrypted virtual machines (VMs) can ensure the security of their operating environment through mechanisms such as encrypted protection of the VM's memory space and access isolation. Building upon this, when an encrypted VM needs to access peripherals such as deep learning units for data processing, TEEIO technology was developed to avoid the risk of data leakage due to peripheral access. TEEIO technology allows certain peripherals to be included within the TEE scope and treated as TEEIO devices. These TEEIO devices are then bound to the encrypted VM through the IOMMU (Input / Output Memory Management Unit). This allows TEEIO devices to securely access the encrypted memory space of the encrypted VM, while non-TEEIO devices are isolated. In other words, TEEIO technology enhances chips such as the System-on-Chip (SoC) and the IOMMU, enabling specific peripherals to be included within the TEE scope and directly connected to the encrypted VM as trusted TEEIO devices. This allows TEEIO devices to securely access the encrypted memory space of the encrypted VM while preventing non-TEEIO devices from stealing data from the encrypted VM.

[0025] However, the E2E (End to End) access mechanism in the modern PCIe (Peripheral Component Interconnect Express) architecture presents new challenges to TEEIO technology, potentially undermining the isolation protection provided by TEEIO and leading to the risk of data leakage in encrypted virtual machines.

[0026] Specifically, ACS (Access Control Services) is a mechanism provided by PCIe to prevent unauthorized communication between devices. When PCIe's ACS is disabled, PCIe devices can directly access other devices via P2P (Peer-to-Peer) communication, bypassing RC (Root Complex) and IOMMU, thereby bypassing the TEE-scope access control mechanism of TEEIO technology. This may lead to direct communication between non-TEEIO devices and TEEIO devices, posing a risk that non-TEEIO devices may steal data from the MMIO space of TEEIO devices. On the other hand, while enabling PCIe's ACS can block P2P access between PCIe devices, PCIe devices can still achieve E2E access at the system level through IO page table mapping. This means that non-TEEIO devices may access the MMIO space of TEEIO devices through E2E paths, posing a risk of data leakage for encrypted virtual machines.

[0027] It should be noted that the RC (Remote Control Unit) acts as a bridge between the CPU and PCIe devices, connecting the CPU, memory, and the PCIe bus. PCIe devices are considered a type of peripheral that uses the PCIe protocol. The MMIO space of a peripheral is a reserved area in the system memory address space used to map the peripheral's control registers. Through the address corresponding to the peripheral's MMIO space in the system memory address space, the CPU or virtual machine can read and write the peripheral's control registers as if reading and writing memory, thereby realizing the control and communication of the peripheral. In other words, the MMIO space is the control entry point of the peripheral and the bridge for communication between the peripheral and the processor.

[0028] To facilitate understanding of P2P communication between peripherals, Figure 2 An example diagram illustrating peripherals communicating via a P2P channel in a PCIe architecture is shown, combined with... Figure 2 As shown, the Root Complex acts as a bridge connecting the CPU, memory, and the PCIe bus, and connects to multiple switches via the Root Port. The Root Port is the port on the Root Complex that connects to PCIe devices. Each switch connects to multiple peripherals using the PCIe protocol (i.e., PCIe devices) and is responsible for forwarding data streams between these peripherals. Figure 2 The dashed lines illustrate the P2P channel between peripherals connected to the Switch; each peripheral uses the PCIe protocol and has MMIO space as the control interface for memory mapping. Figure 2 Based on the above, when the PCIe ACS function is disabled, multiple peripherals connected to the same switch can communicate directly through a P2P channel, bypassing the upper-layer Root Complex and IOMMU. This bypasses the address translation and access control of the Root Complex and IOMMU. If there are non-TEEIO devices and TEEIO devices that are directly connected to the encrypted virtual machine among the multiple peripherals, the non-TEEIO devices may directly access the MMIO space of the TEEIO device through the P2P channel. Although the MMIO space of the TEEIO device is not the encrypted memory space of the encrypted virtual machine, it is the bridge for the encrypted virtual machine to control the TEEIO device and initiate data processing tasks. If a non-TEEIO device illegally accesses or interferes with the MMIO space of the TEEIO device, it may indirectly control the TEEIO device or read the status information of the TEEIO device, resulting in a data leakage security risk for the encrypted virtual machine.

[0029] As can be seen, P2P access is an efficient communication mechanism in the PCIe architecture, but it bypasses access control mechanisms, potentially leading to peripherals accessing each other across different virtual machines and causing data leaks. To mitigate this risk, peripherals that may engage in P2P communication can be grouped into the same IOMMU Group and assigned to the same virtual machine, thus maintaining a secure boundary for communication between peripherals. An IOMMU Group is considered a set of PCIe devices that share the same IOMMU address translation context (page table). By grouping peripherals that may engage in P2P communication into a single group and allowing the entire group to be assigned to only one virtual machine, the isolation and security boundary of peripheral access between virtual machines are ensured. Although the P2P access mechanism has security vulnerabilities, its efficiency has led to its widespread application in high-performance computing and big data processing fields that prioritize high performance.

[0030] One way to block P2P communication is to enable the ACS function of PCIe. When the ACS function is enabled, P2P communication between PCIe devices is prohibited. However, non-TEEIO devices can still access the MMIO space of the TEEIO device in an E2E manner through the IOMMU and IO page table path. For example, if the IO page table is incorrectly configured to allow non-TEEIO devices to access the MMIO area of ​​the TEEIO device, then non-TEEIO devices can illegally read, control or interfere with the TEEIO device, resulting in the risk of leakage of encrypted virtual machine data.

[0031] To facilitate a better understanding of E2E communication between peripherals, Figure 3 An example diagram illustrating E2E access to peripherals in a PCIe architecture is shown, combined with... Figure 3 As shown, the IOMMU is used to control the DMA (Direct Memory Access) access permissions of PCIe devices and manage address translation relationships; the Root Complex acts as a bridge connecting the CPU, memory and PCIe bus, and contains multiple Root Ports, each of which connects to a different Switch; a Switch can connect to multiple peripherals (in the form of PCIe devices), and each peripheral has its own MMIO space; Figure 3The dashed line illustrates the E2E path between peripherals. Peripheral a is a non-TEEIO device and is not included in the TEE scope, while peripheral b is a TEEIO device and is a trusted device, directly connected to the encrypted virtual machine. Peripheral a and peripheral b communicate with each other through the E2E channel, with the access target being the other's MMIO space. The E2E channel passes through the IOMMU and the Root Complex. In this scenario, if the IO page table configuration is incorrect, and peripheral a (non-TEEIO device) is incorrectly authorized to access the MMIO space of peripheral b (TEEIO device), then peripheral a can bypass access control through a legitimate E2E path and illegally read, write, or control peripheral b. Although this unauthorized access does not directly involve the encrypted memory space of the encrypted virtual machine, since the MMIO space of peripheral b (TEEIO device) is the control interface between the encrypted virtual machine and peripheral b, attackers can indirectly steal sensitive information or interfere with the encrypted virtual machine's operation of TEEIO devices, thus posing a risk of data leakage.

[0032] As can be seen from the above description, although TEEIO technology can achieve hardware isolation of peripheral access through IOMMU and device access control, and block P2P communication between PCIe devices through PCIe's ACS function, the E2E communication method of modern PCIe architecture still provides potential unauthorized access paths for non-TEEIO devices, resulting in the risk of data leakage of encrypted virtual machines.

[0033] To facilitate further understanding, the following section will use the device access control mechanism of TEEIO technology to illustrate the challenges that the E2E mechanism poses to the device access isolation upon which TEEIO technology relies. (Example follows.) Figure 4 An example diagram of the communication architecture between a SOC-based encrypted virtual machine and peripherals is shown.

[0034] like Figure 4As shown, the encrypted virtual machine runs in a trusted environment, can run security tasks, and is bound to a TEEIO device; other virtual machines (such as ordinary virtual machines) and applications run in an untrusted environment, originating from the host or other users, and should not access the TEEIO device bound to the encrypted virtual machine; the Host OS runs on the physical machine and manages the entire virtualization platform, such as managing the virtual machine monitor or directly acting as a Hypervisor; the CPU SOC is the central processing unit in the system-on-a-chip, containing the CPU core running the Host OS and virtual machines, and integrating the IOMMU and device access control module; the device access control module is used to determine the source of the request, identify access to the MMIO space of the TEEIO device from the host and virtual machines, and only allow access requests from the encrypted virtual machine; the IOMMU is used to manage address translation for DMA and MMIO access between devices; the TEEIO device is a peripheral device within the TEE scope that is directly connected to the encrypted virtual machine, and the MMIO space is its control interface; non-TEEIO devices are not within the TEE scope and may belong to the Host. The OS or other virtual machine has an independent MMIO space, and non-TEEIO devices are managed by the IOMMU but not protected by the TEE; Depend on Figure 4 As can be seen, the device access control module is responsible for intercepting all access requests from inside the CPU (including the Host OS, other virtual machines, or applications) and determining whether these requests belong to authorized encrypted virtual machines. If not, it will prevent them from accessing the MMIO space of the TEEIO device. Thus, through the linkage between the device access control module and the IOMMU, only encrypted virtual machines are allowed to access their bound TEEIO devices. This ensures that even if the Host OS or other virtual machines have the ability to make requests to the TEEIO device, unauthorized access will be blocked at the SOC level, thereby preventing the TEEIO device from being abused or data from being leaked. Figure 4 While the proposed solution can intercept access to the MMIO space of the TEEIO device from the Host OS and other virtual machines within the SOC, non-TEEIO devices can still access the MMIO space of the TEEIO device via the IOMMU path in an E2E manner. E2E access may originate from the Host OS or other virtual machines. If the IO page table is misconfigured or exploited by attackers, non-TEEIO devices may construct legitimate access transactions to access or even steal data from the MMIO space of the TEEIO device, posing a risk of data leakage to the encrypted virtual machine.

[0035] Based on this, this application embodiment considers enhancing the hardware functionality of the IOMMU by identifying access to the MMIO space of TEEIO devices within the IOMMU. This prevents non-TEEIO devices from stealing MMIO data (MMIO data being the data in the MMIO space) of TEEIO devices through E2E channels in encrypted virtual machine and TEEIO technology scenarios. In an optional implementation, in addition to providing address mapping functionality, the IOMMU of this application embodiment also incorporates an identity and permission check mechanism based on the access initiating device. This checks whether the current DMA request or MMIO access request for the TEEIO device originates from an authorized device or virtual machine, thereby enhancing the granularity of access control over the MMIO space of the TEEIO device. In other words, this application embodiment, by adding a verification and permission identification mechanism for inter-peripheral MMIO access within the IOMMU, prevents non-TEEIO devices from accessing TEEIO devices through E2E channels at the hardware path level. This eliminates the risk of bypassing access control due to IO page table configuration errors or hardware path detours, improves the security of TEEIO technology, and ultimately eliminates the risk of non-TEEIO devices stealing data in the MMIO space of TEEIO devices, thus enhancing data security.

[0036] As an optional implementation Figure 5 An exemplary diagram of an access control system provided in an embodiment of this application is shown. This access control system can be considered as part of a computer. By adding an MMIO access control module inside the IOMMU and combining it with the TEEIO verification mechanism, hardware-level interception and isolation are performed on access to the MMIO space of TEEIO devices by non-TEEIO devices. (Refer to...) Figure 5 The access control system may include: Memory 130 refers to the host's physical memory, also known as system main memory, used to store the operating data required by the operating system and system hardware. In optional implementations, memory can store I / O page tables. That is, the I / O page tables are stored in memory. When the IOMMU processes access requests from peripherals, it can look up the address mapping relationship in the I / O page tables. The lookup result is cached in the IOMMU's TLB (Translation Lookaside Buffer) for fast access. It should be noted that TLB is a high-speed cache structure used to accelerate the translation from virtual addresses to physical addresses. The TLB in the IOMMU is used to cache the mapping from I / O virtual addresses (input / output virtual addresses) to host physical addresses to accelerate access requests initiated by peripherals such as PCIe devices, such as DMA access requests. In this embodiment, the memory I / O page table can be divided into ordinary I / O Page Table (IOPT) and secure I / O Page Table (HPA). Ordinary I / O Page Table (IOPT) is an address mapping table used by ordinary peripherals (such as ordinary PCIe devices, which are non-TEEIO devices). It is configured by the operating system or hypervisor and is used to map the I / O virtual addresses of ordinary peripherals to HPA. Secure I / O Page Table (IOPT) is an address mapping table used by TEEIO devices. It is configured and managed by PSP to prevent ordinary peripherals from misusing or accessing the memory space addresses of TEEIO devices involved in encrypted virtual machines. Therefore, under normal circumstances, such as without considering malicious modification of the ordinary I / O Page Table of non-TEEIO devices, there should be no address conflict between the HPA of non-TEEIO devices and TEEIO devices. TEEIO device 510, a trusted peripheral bound to the encrypted virtual machine, is included in the TEE scope and directly connected to the encrypted virtual machine. This is for illustrative purposes. Figure 5 Examples of TEEIO device A and TEEIO device B are provided. Non-TEEIO devices 520 are ordinary peripherals and are not included in the TEE scope. Both TEEIO devices and non-TEEIO devices are peripherals and each has its own MMIO space. For details about the MMIO space, please refer to the previous description. IOMMU 530 is a hardware module used to manage address translation and access control for peripheral access to memory.

[0037] As an optional implementation, combined Figure 5 As shown, the IOMMU may include: TLB 531, TLB is a high-speed cache inside IOMMU, used to store the mapping relationship between recently used I / O virtual addresses and HPA, to avoid the situation where every access request of peripheral devices (such as DMA request) accesses the I / O page table in memory, thus improving address translation efficiency; The DMA remapping module 532 is used to perform address translation from I / O virtual address to HPA, that is, to translate the I / O virtual address in the access request (such as DMA request) initiated by the peripheral device into HPA. Specifically, when the peripheral device initiates an access request, the DMA remapping module first checks whether the TLB has cached the mapping relationship between the I / O virtual address in the access request and the corresponding HPA. If the TLB hits, the TLB has cached the mapping relationship between the I / O virtual address in the access request and the corresponding HPA, and thus obtains the HPA corresponding to the I / O virtual address in the access request based on the mapping relationship cached by the TLB, and quickly completes the address translation. If the TLB misses, the TLB does not have cached the mapping relationship between the I / O virtual address in the access request and the corresponding HPA. At this time, the DMA remapping module will access the I / O page table in memory to look up the mapping relationship. Furthermore, in the event of a TLB miss, for access requests initiated by ordinary peripherals (such as non-TEEIO devices), the DMA remapping module can access the ordinary IOPT in the lookup memory to find the mapping relationship; for access requests initiated by TEEIO devices, the DMA remapping module can access the safe IOPT in the lookup memory to find the mapping relationship. This distinction between ordinary IOPT and safe IOPT, as well as the DMA remapping module's differentiated lookup of mapping relationships, allows TEEIO devices to be isolated from ordinary peripherals in the memory address space. The TEEIO verification module 533 is an extension module set up in this application embodiment to support the TEEIO security mechanism. It is incorporated into the enhanced IOMMU architecture to identify whether the peripheral that initiates the access request (such as a DMA request or an MMIO access request) belongs to the marked TEEIO device. The identification method can be based on the BDF (Bus-Device-Function) field in the PCIE TLP (Transaction Layer Packet). The PCIE TLP packet is the core message in the PCIE protocol used to transmit read and write instructions and data. The communication content between devices is encapsulated in the TLP packet. The BDF is the unique address identifier of the PCIE device. The identity of the access initiating device can be identified through the BDF field carried in the PCIE TLP packet. In this application embodiment, it is used for access control and trust judgment in the IOMMU. The MMIO access control module 534 is an extension module provided in this embodiment to support the TEEIO security mechanism. It is incorporated into the enhanced IOMMU architecture to specifically intercept unauthorized access to the MMIO space of the TEEIO device by non-TEEIO devices. Specifically, the MMIO access control module has a built-in MMIO Access Control Table (MACT) that records the MMIO address range of the protected TEEIO device. The MMIO access control table is configured only by the trusted BIOS (Basic Input / Output System) through the PSP. Thus, after address translation is completed, if the access request is initiated by a non-TEEIO device, the MMIO access control module can determine whether the HPA falls within the MMIO address range recorded in the MMIO access control table, that is, whether the HPA accessed by the access request belongs to the MMIO address range of the TEEIO device. If so, it indicates that the access request is an unauthorized access to the MMIO space of the TEEIO device by a non-TEEIO device, and thus the access request is blocked.

[0038] Based on the access control system provided in the embodiments of this application, the access control method applied to the IOMMU provided in the embodiments of this application is described below. The description below can be referred to in conjunction with the description above. As an optional implementation, Figure 6 An exemplary flowchart of an access control method provided in an embodiment of this application is shown. This access control method can be applied to an IOMMU. (Refer to...) Figure 6 The access control method may include the following steps.

[0039] Step S610: Obtain the access request of the peripheral device. The access request carries the IO virtual address and the BDF information of the peripheral device.

[0040] Peripherals acting as access initiators can initiate access requests, such as DMA or MMIO access requests, and pass them to the IOMMU for address translation and permission verification. This application requires that all access requests initiated by peripherals must pass through the IOMMU, including but not limited to regular memory access requests and inter-device access requests initiated by peripherals via the PCIe protocol's E2E path. To ensure that all peripheral access requests are controlled by the IOMMU, in scenarios using the PCIe protocol, the PCIe protocol's ACS function should be enabled to prevent unauthorized P2P direct communication between peripherals, thereby avoiding security risks associated with access bypassing the IOMMU. For example, an access request can be an access request initiated by a peripheral via the E2E path when the PCIe protocol's ACS function is enabled.

[0041] The access request initiated by the peripheral device carries the IO virtual address and the peripheral device's BDF information; wherein, the IO virtual address in the access request is the target address of the peripheral device's access and is in the form of a virtual address; the BDF information in the access request is the peripheral device's device identification information; it should be noted that the peripheral device initiating the access request may be a TEEIO device or a non-TEEIO device, and this application embodiment does not limit this. In an optional implementation, when a peripheral device using the PCIe protocol (whether a TEEIO device or a non-TEEIO device) initiates an access request, the access request can be encapsulated into a PCIe TLP packet. This TLP packet contains two key information fields: the target address (i.e., the IO virtual address) and the BDF. When the IOMMU receives the access request, it can extract the peripheral's BDF information from the TLP packet to identify the device identity of the peripheral device initiating the access request, and perform address translation and access permission verification based on the IO virtual address.

[0042] Step S620: Based on the peripheral's BDF information, confirm the peripheral's device identity. The peripheral's device identity is divided into TEEIO devices and non-TEEIO devices.

[0043] When IOMMU receives access requests from peripherals, it can parse the BDF information in the access request, such as extracting the BDF information from the BDF field of the PCIETLP packet, thereby obtaining the peripheral's BDF information. Based on the peripheral's BDF information, it can determine the peripheral's device identity, that is, whether the peripheral initiating the access belongs to the TEEIO device. For example, IOMMU's TEEIO verification module can be responsible for determining the peripheral's device identity. For instance, the TEEIO verification module is used to parse the BDF information in the access request to obtain the peripheral's BDF information, and based on the peripheral's BDF information, it can determine whether the peripheral is a TEEIO device.

[0044] As a further optional implementation, in determining whether the peripheral initiating the access request belongs to a TEEIO device, the IOMMU (such as the IOMMU's TEEIO verification module) can maintain a TEEIO device identification table. This TEEIO device identification table is considered a TEEIO whitelist, recording the BDF information of trusted TEEIO devices. This TEEIO device identification table can be initialized by the PSP or BIOS and written into the IOMMU (such as into the TEEIO verification module). The TEEIO device identification table is read-only and cannot be tampered with. Then, the IOMMU (such as the IOMMU's TEEIO verification module) can match the peripheral's BDF information with the TEEIO device identification table to determine whether the peripheral initiating the access request belongs to a TEEIO device. If the peripheral's BDF information exists in the TEEIO device identification table, then the peripheral is a TEEIO device; if the peripheral's BDF information does not exist in the TEEIO device identification table, then the peripheral is a non-TEEIO device. For example, the IOMMU's TEEIO verification module can extract the peripheral's BDF information from the PCIE TLP packet, and then check whether the extracted BDF information exists in the TEEIO device identifier table. If it does, it is determined that the peripheral that initiated the access request belongs to a TEEIO device; otherwise, it is determined that the peripheral that initiated the access request belongs to a non-TEEIO device.

[0045] Step S630: Perform address translation processing on the IO virtual address to obtain the corresponding HPA.

[0046] After IOMMU obtains the access request from the peripheral (such as the peripheral's PCIE TLP packet), it can extract the IO virtual address of the access request, perform address translation from IO virtual address to HPA, and obtain the HPA corresponding to the IO virtual address.

[0047] In an optional implementation, this embodiment of the application may first check whether the TLB caches the mapping relationship between the IO virtual address carried by the access request and the corresponding HPA; if the TLB caches the mapping relationship between the IO virtual address carried by the access request and the corresponding HPA (i.e., TLB hit), then based on the mapping relationship cached by the TLB, address translation processing is performed to obtain the corresponding HPA; if the TLB does not cache the mapping relationship between the IO virtual address of the access request and the corresponding HPA (i.e., TLB miss), then the memory IO page table is searched, address translation processing is performed, and the HPA corresponding to the IO virtual address of the access request is obtained; if the access request is initiated by a TEEIO device, then when searching the memory IO page table, a secure IOPT is searched, address translation processing is performed, and the HPA corresponding to the IO virtual address of the access request is obtained; if the access request is initiated by a non-TEEIO device, then when searching the memory IO page table, a normal IOPT is searched, address translation processing is performed, and the HPA corresponding to the IO virtual address of the access request is obtained. In other words, when the IOMMU receives an access request from a peripheral device, it parses the BDF information in the access request, such as extracting the BDF information from the BDF field of the PCIE TLP packet, thereby obtaining the peripheral device's BDF information. Based on the peripheral device's BDF information, it determines the peripheral device's identity, that is, whether the peripheral device initiating the access belongs to the TEEIO device category. If it does, then when there is a TLB miss, it searches for the security IOPT, performs address translation processing, and obtains the HPA corresponding to the IO virtual address of the access request. If not, then when there is a TLB miss, it searches for the normal IOPT, performs address translation processing, and obtains the HPA corresponding to the IO virtual address of the access request. For example, the IOMMU's TEEIO verification module can be responsible for peripheral device identity determination. For instance, the TEEIO verification module parses the BDF information in the access request to obtain the peripheral's BDF information, and based on this information, determines whether the peripheral is a TEEIO device. The IOMMU's DMA remapping module can be responsible for performing address translation processing. For instance, the DMA remapping module checks if the TLB caches the mapping relationship between the access request's IO virtual address and the corresponding HPA. If the TLB caches this mapping relationship (i.e., TLB hit), it performs address translation processing based on the cached mapping relationship to obtain the corresponding HPA. If the TLB does not cache this mapping relationship (i.e., TLB miss), and the TEEIO verification module confirms the peripheral is a TEEIO device, it searches for the secure IOPT, performs address translation processing, and obtains the HPA corresponding to the access request's IO virtual address. If the TLB does not cache this mapping relationship (i.e., TLB miss), and the TEEIO verification module confirms the peripheral is a TEEIO device, it searches for the secure IOPT, performs address translation processing, and obtains the HPA corresponding to the access request's IO virtual address. If the TEEIO verification module confirms that the peripheral device is a non-TEEIO device, then the ordinary IOPT is searched, address translation processing is performed, and the HPA corresponding to the IO virtual address of the access request is obtained. In other words, in the optional implementation, the TEEIO verification module is responsible for parsing the BDF field in the access request and determining whether the peripheral initiating the access is a TEEIO device; the DMA remapping module, when a TLB miss occurs, selects to search for a secure IOPT or a normal IOP based on the judgment result of the TEEIO verification module, and performs address translation processing from IO virtual address to HPA.

[0048] Step S640: If the peripheral device is not a TEEIO device, determine whether HPA belongs to the MMIO address range of the TEEIO device. If yes, proceed to step S650; otherwise, proceed to step S660.

[0049] After obtaining the HPA corresponding to the IO virtual address of the access request, if the peripheral that initiated the access request is a non-TEEIO device (the process of determining whether the peripheral is a TEEIO device or a non-TEEIO device can be referred to the previous description), then proceed to step S640 to perform a security post-check after address translation processing, in order to check whether the HPA ultimately accessed by the non-TEEIO device falls within the MMIO address range of the TEEIO device, thereby preventing the non-TEEIO device from accessing the MMIO space of the TEEIO device. Specifically, if the HPA accessed by a non-TEEIO device falls within the MMIO address range of the TEEIO device, it indicates that the non-TEEIO device may indirectly bypass the access control mechanism to access the control interface area (i.e., the MMIO space of the TEEIO device) by constructing a specific IO virtual address. This access behavior has a high security risk and may lead to the behavior of the TEEIO device being controlled or interfered with by the non-TEEIO device. Furthermore, the non-TEEIO device may indirectly infer sensitive information in the encrypted virtual machine by reading the status register of the TEEIO device. Therefore, the IOMMU (such as the MMIO access control module in the IOMMU) should block the access request from the non-TEEIO device, refuse the continued execution of the access request, and report abnormal events. If the HPA accessed by a non-TEEIO device does not fall within the MMIO address range of the TEEIO device, it means that the HPA accessed by a non-TEEIO device is in the normal address space and does not involve the TEEIO device controlled by the encrypted virtual machine. Therefore, it will not cause the risk of unauthorized access. In this case, the IOMMU (such as the MMIO access control module in the IOMMU) can normally allow the access request, so the IOMMU continues to output the HPA to complete the access request.

[0050] It should be noted that when an access request initiated by a non-TEEIO device fails to find the TLB, it searches for a regular IOPT to obtain the corresponding HPA. The HPA falling into the MMIO address range of a TEEIO device may be due to the following reasons: If the IO page table is misconfigured or has a vulnerability, the system may incorrectly configure the MMIO address of the TEEIO device in the ordinary IOPT when configuring the ordinary IOPT. As a result, the MMIO address of the TEEIO device is incorrectly mapped to a non-TEEIO device. In this case, even if the IO virtual address in the access request initiated by the non-TEEIO device is valid, due to the IO page table misconfiguration or vulnerability, the mapped HPA falls into the MMIO range of the protected TEEIO device. Attackers may intentionally construct unauthorized mappings from IO virtual addresses to HPA. For example, when a non-TEEIO device initiates an access request, if the IO page table content is not protected, the attacker may tamper with the IO page table to cause the IO virtual address to be incorrectly mapped to the MMIO space of the TEEIO device. Thus, the attacker can indirectly access the MMIO region of the TEEIO device through the IO virtual address.

[0051] In other words, due to potential misconfiguration or tampering of ordinary IOPTs, some IO virtual addresses may be incorrectly mapped to the MMIO space of TEEIO devices. Therefore, this embodiment of the application, through the MMIO access control module within the IOMMU, re-verifies the HPA output by the DMA remapping module when the peripheral initiating the access request is a non-TEEIO device. This ensures that access requests from non-TEEIO devices will not access the MMIO space of any TEEIO device, effectively preventing unauthorized control and the risk of sensitive information leakage. Therefore, the MMIO access control module in the IOMMU provided in this embodiment of the application can prevent non-TEEIO devices from accessing the MMIO space of TEEIO devices through the HPA verification mechanism, thereby eliminating the risk of non-TEEIO devices stealing data from the MMIO space of TEEIO devices and improving data security.

[0052] To implement the mechanism for the MMIO access control module to verify whether the HPA output by the DMA remapping module has unauthorized access to the MMIO space of the TEEIO device, as an optional implementation, this application embodiment can set up an MMIO access control table (MACT) that is configurable only by the PSP and built into the MMIO access control module. The MMIO access control table records the MMIO address ranges of multiple protected TEEIO devices. Specifically, the MMIO access control table can contain multiple records, and each record includes the MMIO address range of a TEEIO device. The MMIO address range of a TEEIO device is specifically defined by the starting address base of the MMIO space of the TEEIO device and the size size of the MMIO space, i.e., [base, base+size). For ease of understanding, Table 1 below provides an example of the contents of the MMIO access control list, which can be used as a reference.

[0053]

[0054] Table 1 As can be seen, a row in the MMIO access control table defines the address range of the MMIO space of a TEEIO device. That is, a row in the MMIO access control table can be regarded as a record, corresponding to the MMIO address range of a TEEIO device. The starting address of the MMIO space is represented as base, which is the starting position of the MMIO space of the TEEIO device in the physical address. The size of the MMIO space is the size of the address range occupied by the MMIO space of the TEEIO device. Therefore, the address range of the MMIO space of a TEEIO device is calculated as follows: Address range of the MMIO space of a TEEIO device = [base, base+size), that is, the address range of the MMIO space of a TEEIO device includes the starting address base, but does not include the ending address base+size. Furthermore, this embodiment of the application can determine whether the HPA obtained from the address translation process hits the MMIO access control table, so as to determine whether the HPA belongs to the MMIO address range of the TEEIO device; if it hits, it means that the HPA falls within the MMIO address range of a certain record of the TEEIO device in the MMIO access control table. Since the peripheral that initiates the access is not a TEEIO device, the access is regarded as an unauthorized access and is rejected; if it does not hit, it means that the HPA does not fall within any record of the MMIO access control table, there is no unauthorized access, and the access request is allowed.

[0055] It should be noted that the MMIO access control list can be located in the MMIO access control module inside the IOMMU and configured by the PSP during the startup phase. Since the PSP is a trusted security processor in the SOC, its configuration behavior is trustworthy, thereby preventing unauthorized modification of the MMIO access control list.

[0056] Step S650: Deny access request.

[0057] If the HPA accessed by a non-TEEIO device falls within the MMIO address range of the TEEIO device, this embodiment of the application can refuse to execute the access request, block the continued execution of the access request, and further, can also report the corresponding abnormal event.

[0058] Step S660: Continue executing the access request.

[0059] If the HPA accessed by a non-TEEIO device does not fall within the MMIO address range of the TEEIO device, the access request can continue to be executed in this embodiment. The IOMMU can then output the HPA, allowing it to be forwarded to memory along with the access request, ultimately completing the DMA or MMIO access operation. In this case, since the access address does not involve the control space of the protected TEEIO device, the access behavior is considered legal, and the IOMMU does not block or intervene. The peripheral device can access the corresponding memory or resources according to the HPA, thereby completing the normal data transmission or control instruction execution process.

[0060] As can be seen, in this embodiment, if the peripheral initiating the access request is a non-TEEIO device and the HPA (Hyperaddress Translation) matches the MMIO access control list, the access request is rejected; if the peripheral initiating the access request is a non-TEEIO device and the HPA does not match the MMIO access control list, the access request is allowed and the access request continues to be executed; if the peripheral initiating the access request is a TEEIO device, this embodiment may not perform the HPA and MMIO access control list match judgment, and the access request will be allowed and the access request will continue to be executed.

[0061] To facilitate further understanding, combined with Figure 5As shown, taking a non-TEEIO device accessing TEEIO device A as an example, the non-TEEIO device initiates an access request (such as a DMA request or MMIO access request), represented as access TEEIO_A MMIO. The access request carries the IO virtual address and the BDF information of the non-TEEIO device. The IOMMU receives the access request and hands it over to the TEEIO verification module, which determines whether the peripheral initiating the access is a non-TEEIO device based on the BDF information in the access request. Furthermore, the DMA remapping module checks the TLB and performs address translation processing on the IO virtual address in the access request. If the TLB hits, the HPA corresponding to the IO virtual address is obtained; otherwise, the TLB fails to reach the target address. If a miss occurs, the ordinary IOPT in memory is searched to obtain the HPA corresponding to the IO virtual address. Since the device initiating the access is a non-TEEIO device, after obtaining the HPA, further address post-verification is performed, and the HPA is sent to the MMIO access control module. The MMIO access control module determines whether the HPA hits the MMIO access control table. Since this example uses a non-TEEIO device accessing TEEIO device A, the HPA hits the MMIO access control table, indicating that the current access request is an unauthorized access behavior of a non-TEEIO device to the control interface of a TEEIO device. This may be due to a misconfiguration of the ordinary IOPT or the attacker deliberately constructing the IO virtual address of the access request, causing the IO virtual address in the access request to be incorrectly mapped to the MMIO range of the protected TEEIO device. Therefore, the access request needs to be intercepted, the access is denied, and an exception is reported.

[0062] To facilitate further understanding, combined with Figure 5 As shown, taking TEEIO device B accessing TEEIO device A as an example, TEEIO device B initiates an access request (such as a DMA request or MMIO access request), represented as access TEEIO_A MMIO. The access request carries the IO virtual address and the BDF information of TEEIO device B. The IOMMU receives the access request and hands it over to the TEEIO verification module. Based on the BDF information in the access request, it determines that the peripheral initiating the access is a TEEIO device. Then, the DMA remapping module checks the TLB and performs address translation processing on the IO virtual address in the access request. If the TLB hits, the HPA corresponding to the IO virtual address is obtained. If the TLB misses, the safe IOPT in memory is searched to obtain the HPA corresponding to the IO virtual address. Since the peripheral initiating the access is a TEEIO device, after obtaining the HPA, the access request can be directly allowed and the access request can continue to be executed.

[0063] In the access control method provided in this application embodiment, after obtaining an access request, the IOMMU can confirm the device identity of the peripheral based on the BDF information of the peripheral carried in the access request. The device identity of the peripheral is divided into TEEIO devices and non-TEEIO devices. If the device identity of the peripheral is a non-TEEIO device, after performing address translation processing on the IO virtual address carried in the access request to obtain the corresponding HPA, further address post-verification of the HPA is performed to determine whether the HPA belongs to the MMIO address range of the TEEIO device. If so, it indicates that the non-TEEIO device is accessing the MMIO space of the TEEIO device, thereby rejecting the access request. If not, the access request continues to be executed.

[0064] As can be seen, the access control method provided in this application effectively blocks unauthorized access to the MMIO space of a TEEIO device by introducing peripheral identification and address post-verification within the IOMMU. Specifically, when a system configuration error occurs and the MMIO space of a TEEIO device is incorrectly mapped into the IO page table corresponding to a non-TEEIO device, the non-TEEIO device may mistakenly enter the protected MMIO space of the TEEIO device. Alternatively, an attacker may intentionally bypass traditional permission mechanisms to access the MMIO space of a TEEIO device by constructing the IO virtual address of the access request from a non-TEEIO device and by tampering with the IO page table. To avoid the aforementioned situation where non-TEEIO devices unauthorizedly access the MMIO space of a TEEIO device, this application introduces a dual protection mechanism of peripheral identification and HPA address verification in the IOMMU. Even if an attacker controls the contents of the IO page table, they cannot unauthorizedly access the MMIO space of the TEEIO device, thereby eliminating the risk of non-TEEIO devices stealing data from the MMIO space of the TEEIO device. This achieves hardware-level isolation of the relevant control paths of the encrypted virtual machine, significantly improving data security and control security.

[0065] In a further optional implementation, to ensure that TEEIO devices can securely pass through to encrypted virtual machines, embodiments of this application may rely on a trusted BIOS and a PSP to jointly complete key security control measures such as MMIO address isolation, MMIO access control table configuration, and IO page table allocation for TEEIO devices. Specifically, the BIOS running when the computer system starts is developed by the chip manufacturer and has completed integrity measurement and digital signature verification. Thus, the trusted BIOS that has passed integrity measurement and digital signature verification is embedded in the chip motherboard (such as a SOC motherboard) and cannot be modified by subsequent software. For example, the BIOS firmware that has passed integrity measurement and digital signature verification is written to a non-volatile memory chip on the motherboard, thereby completing the burning process at the factory stage to achieve the embedding of the BIOS in the chip motherboard. When a TEEIO device is assigned (passed through) to an encrypted virtual machine, the BIOS can call or drive the PSP, causing the PSP to write the MMIO address range of the TEEIO device into the IOMMU. Specifically, it sets a corresponding record in the MMIO access control table built into the IOMMU to write the MMIO address range of the TEEIO device (the composition of the MMIO access control table can be referred to the previous description, which will not be elaborated here). This marks the MMIO space address of the protected TEEIO device in the MMIO access control table of the IOMMU, so as to intercept and judge unauthorized access of non-TEEIO devices in the future. In other words, the MMIO access control table is configured by the PSP. Specifically, when a TEEIO device is assigned to an encrypted virtual machine, the BIOS calls or drives the PSP, causing the PSP to set a corresponding record in the MMIO access control table built into the IOMMU to write the MMIO address range of the TEEIO device. Meanwhile, the PSP can manage secure IOPTs for TEEIO devices in memory. That is, the PSP not only configures the MMIO access control table (located in the IOMMU) for TEEIO devices, but also configures and manages secure IOPTs (located in memory) for TEEIO devices so that the secure IOPTs can be used for address translation processing in the IOMMU. Unlike ordinary IOPTs (configured by the host OS or Hypervisor), secure IOPTs are only valid for TEEIO devices and are configured and managed by the PSP, which can prevent them from being tampered with.

[0066] Furthermore, when configuring a secure IOPT for TEEIO devices, the PSP can assign an HPA to each TEEIO device. When assigning an HPA to each TEEIO device, multiple TEEIO devices within the same encrypted virtual machine can share an HPA and / or have their own independent HPA. Moreover, there are no address conflicts between the HPAs of TEEIO devices from different encrypted virtual machines. That is, when the PSP assigns an HPA to a specific TEEIO device within a specific encrypted virtual machine, it needs to ensure that there are no MMIO space addresses belonging to other TEEIO devices within the same encrypted virtual machine. In other words, multiple TEEIO devices can directly connect to the same encrypted virtual machine, and thus, multiple TEEIO devices directly connected to the same encrypted virtual machine can allocate shared addresses as needed. A shared HPA is used to enable collaborative work between multiple TEEIO devices on the same encrypted virtual machine. Multiple TEEIO devices that are passed through to the same encrypted virtual machine can also have their own independent HPA. For example, a TEEIO device that is passed through to the same encrypted virtual machine may have an independent HPA, as well as a shared HPA shared with other TEEIO devices that are passed through to the same encrypted virtual machine. When the PSP allocates an HPA to a TEEIO device on a specific encrypted virtual machine, it must also ensure that the allocated HPA does not conflict with the HPA used by TEEIO devices on other encrypted virtual machines. In other words, the HPAs of TEEIO devices on different encrypted virtual machines must be isolated from each other to ensure the security and isolation of memory access between different encrypted virtual machines.

[0067] Ultimately, by configuring the BIOS and security processor at the software layer, it is possible to prevent non-TEEIO devices from accessing the MMIO space of TEEIO devices through E2E or other means, thereby improving overall security.

[0068] Based on the access control method provided in the embodiments of this application, the functions of the components inside the IOMMU can be configured. The description below can be referred to in correspondence with the description above.

[0069] In the optional implementation, combined Figure 5 As shown, the TEEIO verification module within the IOMMU is used to confirm the device identity of a peripheral based on its BDF information when the IOMMU receives an access request from the peripheral. The device identity of a peripheral is divided into TEEIO devices and non-TEEIO devices. The access request carries the IO virtual address and the BDF information of the peripheral. The DMA remapping module is used to perform address translation processing on the I / O virtual address to obtain the corresponding HPA; The MMIO access control module is used to determine whether the HPA belongs to the MMIO address range of the TEEIO device if the peripheral device is not a TEEIO device. If the HPA belongs to the MMIO address range of the TEEIO device, the access request is rejected. If the HPA does not belong to the MMIO address range of the TEEIO device, the access request is executed.

[0070] In a further optional implementation, the IOMMU is configured with an MMIO access control table, which is configured by the security processor and records the MMIO address ranges of multiple protected TEEIO devices. The MMIO access control table contains multiple records, and each record includes the MMIO address range of one TEEIO device. The MMIO address range of one TEEIO device is determined by the starting address of the MMIO space of the TEEIO device and the size of the MMIO space. Correspondingly, the MMIO access control module, used to determine whether the HPA belongs to the MMIO address range of the TEEIO device, includes: Determine if HPA hits the MMIO access control list; If the HPA hits the MMIO access control table, then the HPA belongs to the MMIO address range of the TEEIO device; If the HPA does not hit the MMIO access control table, then the HPA does not belong to the MMIO address range of the TEEIO device.

[0071] As an optional implementation, the MMIO access control table is configured by the security processor as follows: when the TEEIO device is assigned to the encrypted virtual machine, the BIOS calls or drives the PSP, causing the PSP to set a record in the MMIO access control table built into the IOMMU to write the MMIO address range of the TEEIO device. The BIOS undergoes integrity measurement and digital signature verification and is embedded in the chip motherboard.

[0072] As an optional implementation, the TEEIO verification module is used to confirm the device identity of the peripheral based on the peripheral's BDF information, including: The peripheral's BDF information is matched with the TEEIO device identification table to determine whether the peripheral that initiated the access request belongs to a TEEIO device; the TEEIO device identification table records the BDF information of trusted TEEIO devices. If the peripheral's BDF information exists in the TEEIO device identifier table, then the peripheral is a TEEIO device; If the peripheral's BDF information does not exist in the TEEIO device identifier table, then the peripheral is a non-TEEIO device.

[0073] As an optional implementation, the DMA remapping module is used to perform address translation processing on the IO virtual address to obtain the corresponding HPA, including: Check if the TLB caches the mapping between the IO virtual address carried in the access request and the corresponding HPA; If the TLB cache has a mapping relationship between the IO virtual address carried by the access request and the corresponding HPA, then based on the mapping relationship in the TLB cache, address translation processing is performed to obtain the corresponding HPA; If the TLB does not cache the mapping between the IO virtual address carried by the access request and the corresponding HPA, then the memory IO page table is searched, address translation is performed, and the corresponding HPA is obtained. Specifically, if the access request is initiated by a TEEIO device, the secure IOPT is looked up in the memory's IO page table, address translation is performed, and the corresponding HPA is obtained. If the access request is initiated by a non-TEEIO device, the ordinary IOPT is looked up in the memory's IO page table, address translation is performed, and the corresponding HPA is obtained. The ordinary IOPT is an address mapping table used by ordinary peripherals and is configured by the operating system or hypervisor. The secure IOPT is an address mapping table used by TEEIO devices and is configured and managed by the security processor. When configuring a secure IOPT for a TEEIO device, the security processor assigns an HPA to the TEEIO device. Multiple TEEIO devices within the same encrypted virtual machine share an HPA and / or have their own independent HPA. There are no address conflicts between the HPAs of TEEIO devices in different encrypted virtual machines.

[0074] As an optional implementation, the peripheral access request can be specifically an access request initiated by the peripheral through the E2E path when the ACS function of the PCIE protocol is enabled, and the access request is encapsulated as a PCIE TLP packet; wherein, when the ACS function of the PCIE protocol is enabled, P2P direct communication between peripherals is blocked.

[0075] In a further optional implementation, embodiments of this application also provide a chip, such as a SOC chip, including the IOMMU provided in embodiments of this application.

[0076] In a further optional implementation, embodiments of this application also provide a computer device, such as a terminal device or a server device, including the chip provided in embodiments of this application, or the access control system provided in embodiments of this application.

[0077] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0078] While the embodiments disclosed above are described in this application, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. An access control method, characterized in that, Applied to IOMMU, the method includes: Obtain an access request from a peripheral device, the access request carrying an I / O virtual address and the BDF information of the peripheral device; Based on the peripheral's BDF information, confirm the peripheral's device identity. The peripheral's device identity is divided into TEEIO devices and non-TEEIO devices. For the I / O virtual address, perform address translation processing to obtain the corresponding HPA; If the peripheral device is not a TEEIO device, determine whether the HPA belongs to the MMIO address range of the TEEIO device. If the HPA belongs to the MMIO address range of the TEEIO device, the access request is denied. If the HPA is not within the MMIO address range of the TEEIO device, continue to execute the access request.

2. The method according to claim 1, characterized in that, The determination of whether HPA belongs to the MMIO address range of the TEEIO device includes: Determine if HPA hits the MMIO access control table; the MMIO access control table is configured by the security processor and records the MMIO address ranges of multiple protected TEEIO devices. The MMIO access control table contains multiple records, and each record includes the MMIO address range of one TEEIO device. The MMIO address range of one TEEIO device is determined by the starting address of the MMIO space of the TEEIO device and the size of the MMIO space. If the HPA hits the MMIO access control table, then the HPA belongs to the MMIO address range of the TEEIO device; If the HPA does not hit the MMIO access control table, then the HPA does not belong to the MMIO address range of the TEEIO device.

3. The method according to claim 2, characterized in that, The MMIO access control table is configured by the security processor as follows: when a TEEIO device is assigned to an encrypted virtual machine, the BIOS calls or drives the security processor, causing the security processor to set a corresponding record in the MMIO access control table built into the IOMMU, so as to write the MMIO address range of the TEEIO device. The BIOS undergoes integrity measurement and digital signature verification and is embedded in the chip motherboard.

4. The method according to claim 2, characterized in that, The process of confirming the device identity of a peripheral based on its BDF information includes: The peripheral's BDF information is matched with the TEEIO device identification table to determine whether the peripheral that initiated the access request belongs to a TEEIO device; the TEEIO device identification table records the BDF information of trusted TEEIO devices. If the peripheral's BDF information exists in the TEEIO device identifier table, then the peripheral is a TEEIO device; If the peripheral's BDF information does not exist in the TEEIO device identifier table, then the peripheral is a non-TEEIO device.

5. The method according to any one of claims 1-4, characterized in that, The process of performing address translation on the IO virtual address to obtain the corresponding HPA includes: Check if the TLB caches the mapping between the IO virtual address carried in the access request and the corresponding HPA; If the TLB cache has a mapping relationship between the IO virtual address carried by the access request and the corresponding HPA, then based on the mapping relationship in the TLB cache, address translation processing is performed to obtain the corresponding HPA; If the TLB does not cache the mapping between the IO virtual address carried by the access request and the corresponding HPA, then the memory IO page table is searched, address translation is performed, and the corresponding HPA is obtained. Specifically, if the access request is initiated by a TEEIO device, the secure IOPT is looked up in the memory's IO page table, address translation is performed, and the corresponding HPA is obtained. If the access request is initiated by a non-TEEIO device, the ordinary IOPT is looked up in the memory's IO page table, address translation is performed, and the corresponding HPA is obtained. The ordinary IOPT is an address mapping table used by ordinary peripherals and is configured by the operating system or hypervisor. The secure IOPT is an address mapping table used by TEEIO devices and is configured and managed by the security processor. When configuring a secure IOPT for a TEEIO device, the security processor assigns an HPA to the TEEIO device. Multiple TEEIO devices within the same encrypted virtual machine share an HPA and / or have their own independent HPA. There are no address conflicts between the HPAs of TEEIO devices in different encrypted virtual machines.

6. The method according to claim 1, characterized in that, The access request is an access request initiated by the peripheral device through the E2E path when the ACS function of the PCIE protocol is enabled. The access request is encapsulated as a PCIE TLP packet. When the ACS function of the PCIE protocol is enabled, P2P direct communication between peripheral devices is blocked.

7. An IOMMU, characterized in that, include: The TEEIO verification module is used to confirm the device identity of a peripheral based on the peripheral's BDF information when the IOMMU obtains an access request from the peripheral. The device identity of the peripheral is divided into TEEIO devices and non-TEEIO devices. The access request carries the IO virtual address and the peripheral's BDF information. The DMA remapping module is used to perform address translation processing on the I / O virtual address to obtain the corresponding HPA; The MMIO access control module is used to determine whether the HPA belongs to the MMIO address range of the TEEIO device if the peripheral device is not a TEEIO device. If the HPA belongs to the MMIO address range of the TEEIO device, the access request is rejected. If the HPA does not belong to the MMIO address range of the TEEIO device, the access request is executed.

8. The IOMMU according to claim 7, characterized in that, The IOMMU is equipped with an MMIO access control table, which is configured by the security processor and records the MMIO address ranges of multiple protected TEEIO devices. The MMIO access control table contains multiple records, and each record includes the MMIO address range of one TEEIO device. The MMIO address range of one TEEIO device is determined by the starting address of the MMIO space of the TEEIO device and the size of the MMIO space. The MMIO access control module is used to determine whether the HPA belongs to the MMIO address range of the TEEIO device, including: Determine if HPA hits the MMIO access control list; If the HPA hits the MMIO access control table, then the HPA belongs to the MMIO address range of the TEEIO device; If the HPA does not hit the MMIO access control table, then the HPA does not belong to the MMIO address range of the TEEIO device.

9. The IOMMU according to claim 7, characterized in that, The TEEIO verification module is used to confirm the device identity of a peripheral based on its BDF information. This includes matching the peripheral's BDF information with the TEEIO device identification table to determine whether the peripheral initiating the access request belongs to a TEEIO device. The TEEIO device identification table records the BDF information of trusted TEEIO devices. If the peripheral's BDF information exists in the TEEIO device identification table, the peripheral is a TEEIO device. If the peripheral's BDF information does not exist in the TEEIO device identification table, the peripheral is a non-TEEIO device. The DMA remapping module is used to perform address translation processing on IO virtual addresses to obtain the corresponding HPA. This includes: checking whether the TLB caches the mapping relationship between the IO virtual address carried by the access request and the corresponding HPA; if the TLB caches the mapping relationship between the IO virtual address carried by the access request and the corresponding HPA, then based on the mapping relationship cached by the TLB, address translation processing is performed to obtain the corresponding HPA; if the TLB does not cache the mapping relationship between the IO virtual address carried by the access request and the corresponding HPA, then the memory IO page table is searched, address translation processing is performed, and the corresponding HPA is obtained. Specifically, if the access request is initiated by a TEEIO device, the secure IOPT is looked up in the memory's IO page table, address translation is performed, and the corresponding HPA is obtained. If the access request is initiated by a non-TEEIO device, the ordinary IOPT is looked up in the memory's IO page table, address translation is performed, and the corresponding HPA is obtained. The ordinary IOPT is an address mapping table used by ordinary peripherals and is configured by the operating system or hypervisor. The secure IOPT is an address mapping table used by TEEIO devices and is configured and managed by the security processor. When configuring a secure IOPT for a TEEIO device, the security processor assigns an HPA to the TEEIO device. Multiple TEEIO devices within the same encrypted virtual machine share an HPA and / or have their own independent HPA. There are no address conflicts between the HPAs of TEEIO devices in different encrypted virtual machines.

10. An access control system, characterized in that, include: The IOMMU as described in any one of claims 7-9; The memory's I / O page tables are divided into ordinary IOPTs and secure IOPTs; ordinary IOPTs are address mapping tables used by ordinary peripherals and configured by the operating system or hypervisor; secure IOPTs are address mapping tables used by TEEIO devices and configured and managed by the security processor. TEEIO devices, trusted peripherals bound to encrypted virtual machines, are included in the TEE scope and can be directly connected to encrypted virtual machines for use; Non-TEEIO devices are not included in the TEE scope.

11. A chip, characterized in that, Includes the IOMMU as described in any one of claims 7-9.

12. A computer device, characterized in that, This includes the chip as described in claim 11, or the access control system as described in claim 10.

Images