Methods and systems for encryption and integrity protection of page tables in input / output memory management units

Abstract

This application proposes a method and system for encrypting and protecting the integrity of page tables in an Input / Output Memory Management Unit (IOMMU), relating to computer technology and data processing technology. The method includes: allocating page tables for a new security domain Input / Output Address Space Identifier (IOASID) and generating plaintext basic page table entries; determining the corresponding page table protection key based on the security domain IOASID and obtaining a hardware-maintained monotonic security version number; obtaining the encryption result and message authentication code through hardware encryption and integrity calculations of the security-enhanced IOMMU based on the page table protection key, IOASID, and monotonic security version number; and encapsulating the encryption result, message authentication code, and monotonic security version number into an enhanced encrypted page table entry and writing it into system memory. This application protects the confidentiality and integrity of the IOMMU page tables in a trusted execution environment, performs low-latency page table decryption and integrity verification without software intervention, and defends against malicious attacks.

Description

Technical Field

[0001] This application relates to the fields of computer technology and data processing technology, and in particular to a method and system for encrypting and protecting the integrity of page tables in an input / output memory management unit. Background Technology

[0002] In related technologies, the IOMMU page table is stored in system memory in plaintext, making it vulnerable to being read back and stolen by malicious VMMs (Hypervisors), attacked drivers, or software vulnerabilities. This can lead to the leakage of sensitive information such as the physical address of the DMA target, seriously threatening data confidentiality. Furthermore, the IOMMU cannot perform hardware-level verification of the integrity of the page table content, allowing attackers to bypass IOMMU access control by constructing forged mapping entries or maliciously replaying old versions of the page table, thereby enabling the illegal redirection and tampering of TEE or virtual machine data. All of these factors can lead to vulnerabilities in the security and integrity of core data.

[0003] The IOMMU mechanism relies on an untrusted VMM or operating system to load page tables, lacking the ability to jointly generate, load, and authenticate keys with hardware RoT, and cannot independently verify the trustworthiness of the page table creator and source. If the critical keys protecting the IOMMU page tables are maintained by software (such as a regular kernel or Trusted Execution Environment (TEE) software), they are vulnerable to privilege escalation attacks or side-channel attacks. The lack of a hardware secure key storage module and protection mechanism makes it difficult to guarantee the controllability and confidentiality of the key's lifecycle. In scenarios involving virtualization and multi-tenancy, the lack of efficient, fine-grained hardware mechanisms to ensure complete isolation of page table protection keys in different security domains (such as different VMs or TEE instances) poses risks of cross-domain key access and page table replay between security domains. All of these factors may lead to a lack of root of trust and key management defects.

[0004] The page table translation path lacks hardware-accelerated low-latency encryption and verification. Even when using software to encrypt or sign the page table, the IOMMU incurs significant performance overhead during TLB filling or page table traversal, making it difficult to meet the low-latency address translation requirements of high-speed DMA devices (such as network and storage accelerators). The IOMMU security mechanism focuses on address translation control and is insufficient in dealing with complex attack vectors, including DMA bypass and illegal I / O memory read / write, failing to build a comprehensive security protection covering the entire I / O subsystem. These factors may lead to performance bottlenecks and an inadequate security framework.

[0005] Therefore, how to protect the confidentiality and integrity of IOMMU page tables in a trusted execution environment, perform low-latency page table decryption and integrity verification without relying on software intervention, and defend against coordinated attacks by malicious operating systems, malicious VMMs, and DMA devices has become an important research direction. Summary of the Invention

[0006] This application aims to at least partially address one of the technical problems in the related art. The technical solution disclosed herein is as follows:

[0007] The first aspect of this application proposes a method for encrypting and protecting the integrity of page tables in an input / output memory management unit, including:

[0008] Allocate page table pages for the new security domain input / output address space identifier IOASID, and generate plaintext base page table entries;

[0009] The corresponding page table protection key is determined based on the security domain IOASID, and the monotonic security version number maintained by the hardware is obtained. The IOASID is bound to the independently derived page table protection key.

[0010] Based on the page table protection key, IOASID, and monotonic security version number, the encryption result and message authentication code are obtained through hardware encryption and integrity calculation of the security-enhanced input / output memory management unit (IOMMU).

[0011] The encryption result, message authentication code, and monotonic security version number are encapsulated into an enhanced encrypted page table entry and written into system memory. The message authentication code includes at least the encryption result, IOASID, and monotonic security version number.

[0012] In some implementations, based on the page table protection key, IOASID, and monotonic security version number, the encryption result and message authentication code are obtained through security-enhanced IOMMU hardware encryption and integrity calculations, including:

[0013] Encrypt the fields in the page table entry based on the page table protection key, IOASID, and monotonic security version number, and obtain the encryption result;

[0014] Based on the encryption result, page table protection key, IOASID, monotonic security version number, and control fields, the message authentication code is calculated and generated.

[0015] In some implementations, before allocating a page table page for a new security domain IOASID, the following steps are also included:

[0016] Obtain the root key from the hardware root of trust, anchor the root key during the system startup phase, and obtain the boot random number;

[0017] Obtain the device identifier, perform key derivation operation based on the root key, device identifier and bootstrap random number, and obtain the input / output memory management unit master key IMK;

[0018] The IMK is injected into the secure key storage module via the on-chip secure bus or interconnect. The secure key storage module includes an unreadable secure register array.

[0019] For each security context, a key derivation operation is performed based on the context identifier of the security context and the IMK in the security key storage module to obtain the page table protection key. The context identifier includes the virtual machine identifier, IOASID, or security environment information.

[0020] In some implementations, it also includes:

[0021] Bind the page table protection key to the corresponding direct memory access request context index;

[0022] In response to the detection of a security context switch event, a hardware-based instantaneous zeroing operation is performed on the page table protection key, deleting the page table protection key.

[0023] In some implementations, it also includes:

[0024] In response to receiving a direct memory access request from an external device, extract the context field from the direct memory access request. The context field includes the IOASID.

[0025] The page table protection key index is found based on the IOASID in the context field. The hardware key handle of the found page table protection key is loaded into the working register via on-chip secure interconnect. The latest historical monotonic security version number threshold bound to this context is loaded into the version number comparator for freshness checking.

[0026] The enhanced encrypted entry corresponding to the target page table entry is read through the memory interface, and its internal fields are parsed to extract the page table entry content. The page table entry content includes at least the encrypted physical address field, message authentication code, monotonic security version number and control field.

[0027] In the IOMMU address translation pipeline, at least one of the following is performed in hardware: integrity verification and target address decryption. An atomicity security check is performed by a hardware comparator. If the security verification passes, the decrypted page table entry is written to the security cache.

[0028] In some implementations, it also includes:

[0029] The decrypted physical address field is sent to the backend memory subsystem, and DMA requests are processed; and / or,

[0030] After translation is complete, hardware nullification is performed on the hardware key handle and decryption intermediate state in the working register.

[0031] In some implementations, performing at least one of integrity verification and target address decryption on the read page table entry content in hardware, including:

[0032] The integrity authentication code is obtained by calculating the encrypted physical address field, control field, and monotonic security version number in the page table entry content using the loaded page table protection key; and / or,

[0033] Use the loaded page table protection key to decrypt the encrypted physical address field in the page table entry content to obtain the decrypted physical address field.

[0034] In some implementations, atomicity safety checks are performed using a hardware comparator, including:

[0035] If the integrity authentication code is the same as the message authentication code in the page table entry content, the monotonic security version number in the page table entry content satisfies the monotonically increasing constraint, and the enhanced encryption entry is generated by encryption using the page table protection key bound to the same IOASID as the direct memory access request, then the security verification is deemed successful.

[0036] In some implementations, it also includes:

[0037] If the integrity authentication code is different from the message authentication code in the page table entry content, or the monotonic security version number in the page table entry content does not meet the monotonically increasing constraint, or the page table protection key bound to the same IOASID is encrypted for the enhanced encryption entry non-direct memory access request, the security verification is determined to fail.

[0038] Triggers an unmaskable direct memory access security violation exception and atomically terminates the current direct memory access translation pipeline, blocking access from external devices.

[0039] A second aspect of this application provides an input / output memory management unit page table encryption and integrity protection system, comprising:

[0040] The root of trust and key management unit is used to perform hardware-based secure loading, binding, and management of page table protection keys during system startup and security context switching phases.

[0041] The security-enhanced input / output memory management unit includes a security key storage module, a page table encryption / decryption module, and a page table integrity detection module, which are used for security key storage, page table encryption / decryption, page table integrity detection, and secure caching of page table entry contents.

[0042] Software component unit used to build encrypted page tables;

[0043] The input / output memory management unit page table encryption and integrity protection system is also used to implement the method described in the first aspect embodiment above.

[0044] A third aspect of this application provides an electronic device, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute instructions to implement the input / output memory management unit page table encryption and integrity protection method provided in the first aspect of this application.

[0045] The fourth aspect of this application provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by the processor of an electronic device, enables the electronic device to perform the input / output memory management unit page table encryption and integrity protection method provided in the first aspect of this application.

[0046] This application protects the confidentiality and integrity of IOMMU page tables in a trusted execution environment, performs low-latency page table decryption and integrity verification without relying on software intervention, and defends against coordinated attacks by malicious operating systems, malicious VMMs, and DMA devices.

[0047] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0048] Figure 1 This is a structural block diagram of an input / output memory management unit page table encryption and integrity protection system according to an embodiment of this disclosure;

[0049] Figure 2 This is a flowchart of an embodiment of the input / output memory management unit page table encryption and integrity protection method according to this application;

[0050] Figure 3 This is a structural diagram of an E-PTE according to an embodiment of this application;

[0051] Figure 4 This is a schematic diagram of the E-PTE construction and writing process according to an embodiment of this application;

[0052] Figure 5 This is a flowchart of an embodiment of the input / output memory management unit page table encryption and integrity protection method according to this application;

[0053] Figure 6 This is a schematic diagram of a key security loading process according to an embodiment of this application;

[0054] Figure 7 This is a flowchart of an embodiment of the input / output memory management unit page table encryption and integrity protection method according to this application;

[0055] Figure 8 This is a schematic diagram of the DMA translation and verification process according to an embodiment of this application;

[0056] Figure 9 This is a structural block diagram of an input / output memory management unit page table encryption and integrity protection system according to an embodiment of this application;

[0057] Figure 10 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0058] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0059] The acquisition, storage, and application of information and data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0060] The terminology used in this application is described below.

[0061] IOMMU (Import Output Memory Management Unit) is a hardware technology in a computer system used to manage and map the physical addresses of direct memory access (DMA) devices. Its function is similar to the CPU's memory management unit (MMU).

[0062] A Virtual Machine Monitor (VMM), also known as a Hypervisor, is a software layer that manages physical computing resources and supports the parallel operation of multiple virtual machines. It enables logical isolation and allocation of hardware resources.

[0063] A virtual machine (VM) is a computer program or system that simulates the hardware operating environment of a physical computer through software, enabling multiple operating systems to run simultaneously on the same physical machine.

[0064] Translation Lookaside Buffer (TLB), also known as page table cache or address lookaside cache, is a dedicated hardware cache in the CPU used to accelerate the translation of virtual addresses to physical addresses. It belongs to the Content Addressable Memory (CAM) type.

[0065] Direct Memory Access (DMA) is a technology in computer systems that allows peripherals to directly transfer data with memory. It enables high-speed data transfer through a DMA controller (DMAC) without the need for full central processing unit intervention, effectively reducing CPU load.

[0066] AES-GCM-SIV represents an AEAD encryption algorithm with authentication encryption, anti-reuse, and anti-replay capabilities.

[0067] MAC (Message Authentication Code) refers to a message authentication code used for integrity and authentication.

[0068] Nonce, a monotonic security version number, is a one-time value used to prevent replay attacks and implement version control.

[0069] IOVA (IO Virtual Address) represents the virtual address seen by the device.

[0070] PA (Physical Address) represents the system's actual physical address.

[0071] RISC-V is an open instruction set architecture.

[0072] BootROM (Diskless Boot ROM Interface) is a firmware interface used to enable remote booting of devices, and is usually embedded inside a network card or chip.

[0073] The following describes, with reference to the accompanying drawings, a method and system for encrypting and protecting the page table of the input / output memory management unit according to an embodiment of this application.

[0074] Figure 1 This is a structural block diagram of an input / output memory management unit page table encryption and integrity protection system according to an embodiment of this disclosure, as shown below. Figure 1 As shown, the input / output memory management unit page table encryption and integrity protection system 100 includes:

[0075] The root of trust and key management unit 110 is used to perform hardware-based secure loading, binding and management of page table protection keys during the system startup phase and security context switching phase.

[0076] The security-enhanced input / output memory management unit 120 includes a security key storage module, a page table encryption / decryption module, and a page table integrity detection module, which are used for security key storage, page table encryption / decryption, page table integrity detection, and secure caching of page table entry content.

[0077] Software component unit 130 is used to construct encrypted page tables.

[0078] Furthermore, the Root of Trust and Key Management Unit (ITKU) of the IOMMU comprises a Device Unique Key (DRK), a Hardware Key Derivation Module (KDF), a ROM-based secure loader, and an on-chip secure read-only storage module. As an extension of the system-level HRoT, the ITKU forms a complete trust chain with the BootROM. The ITKU internally stores the Device Unique Root Key (DRK) and derives the IOMMU Master Key (IMK) through the hardware KDF. The IMK is injected into the Secure Key Storage Module (SKR) within the Security Enhanced Input / Output Memory Management Unit (SE-IOMMU) in a non-peepable manner via the on-chip secure bus or interconnect, thus constructing a hardware-based, software-free key loading path to ensure that the IMK is not exposed through a software path.

[0079] Optionally, the Security-Enhanced Input / Output Memory Management Unit, i.e., the Security-Enhanced IOMMU (SE-IOMMU), has internal core components including a secure key storage module, an IOMMU secure page table protection engine (including a page table encryption / decryption module, a page table integrity detection module, and a secure cache module), and an IOMMU context security isolation module, wherein:

[0080] SKR employs a write-only secure register array and supports debug-lock. Each encrypted page table context (identified by IOASID / SKID) is bound to a unique page table protection key K. PT And when a security context switching event occurs (such as when the IOMMU / Hypervisor performs an hfence operation), K is performed. PT Hardware instantaneous miniaturization ， Ensure key isolation and data scavenging protection in multi-tenant environments. hfence operations are used to manage the consistency of virtual memory address translation caches (such as TLB).

[0081] The page table encryption / decryption module (PT-Crypto) in the IOMMU Secure Page Table Protection Engine (SPU) is a hardware-accelerated encryption / decryption engine used to dynamically encrypt and decrypt target addresses in encrypted page table entries (E-PTEs) of the IOMMU.

[0082] The Page Table Integrity Detection Module (PT-MAC) in the IOMMU Secure Page Table Protection Engine (SPU) is a hardware verification engine responsible for calculating and comparing the Message Authentication Code (MAC) in the E-PTE. A key enhancement of this module is that it incorporates a random number (Nonce) or version number counter managed by the TEE / hardware when calculating the MAC. By verifying that the MAC contains the correct counter value, this module can effectively detect and block replay attacks targeting older encrypted page table entries, ensuring the freshness and integrity of the page tables.

[0083] The Secure PT Cache in the IOMMU Secure Page Table Protection Engine (SPU) is an enhanced IOTLB where cached entries contain security state and key indexes.

[0084] The IOMMU Context Security Isolation Module (ICSM) is a functional unit that maps the device identifier (PCIe Device ID), service set identifier (SSID), or RISC-V IOASID) in a DMA request to the page table protection key K. PT An index is used to implement hardware binding between devices and keys. A hardware context switching mechanism prevents the VMM from forging IDs to bypass page table protection.

[0085] The software component unit (TE-PTB) is deployed in a trusted execution environment (such as RISC-V Secure Monitor) and is responsible for building encrypted page tables. This software uses K derived from ITKU. PT The page table entries (target physical address field) are encrypted, and a MAC is generated and written to memory to ensure that the page table remains confidential and intact even under the control of an untrusted VMM.

[0086] Figure 2 This is a flowchart of an embodiment of the input / output memory management unit page table encryption and integrity protection method according to this application, as follows: Figure 2 As shown, the method includes the following steps:

[0087] S201, allocate a page table page for the new security domain input / output address space identifier IOASID, and generate the plaintext of the base page table entry.

[0088] S202, determine the corresponding page table protection key based on the security domain IOASID, and obtain the monotonic security version number maintained by the hardware, wherein the IOASID is bound to the independently derived page table protection key.

[0089] S203, based on the page table protection key, IOASID, and monotonic security version number, obtains the encryption result and message authentication code through hardware encryption and integrity calculation of the security-enhanced input / output memory management unit (IOMMU).

[0090] The fields in the page table entry are encrypted using the page table protection key, IOASID, and monotonic security version number, and the encryption result is obtained.

[0091] Based on the encryption result, page table protection key, IOASID, monotonic security version number, and control fields, the message authentication code is calculated and generated.

[0092] S204 encapsulates the encryption result, message authentication code, and monotonic security version number into an enhanced encrypted page table entry and writes it into system memory. The message authentication code includes at least the encryption result, IOASID, and monotonic security version number.

[0093] The following section details the construction and writing process of the TE-PTB Enhanced Page Table Entry (E-PTE) in this application.

[0094] The E-PTE structure diagram is as follows: Figure 3 As shown, the E-PTE of the encrypted page table entry is 512 bits (64 bytes), it adopts a single cache line design, and is protected by AES-GCM-SIV.

[0095] Optionally, this process is executed by the TE-PTB (Trusted Enhanced Page Table Builder) software component running in a Trusted Execution Environment (TEE) or privileged Monitor enclave on a RISC-V platform. TE-PTB is the only software in the Trusted Computing Base with access permissions to page table entries (PTEs), and it is responsible for the secure handling of sensitive fields (including target physical addresses, permission bit combinations, etc.) in page table entries (PTEs).

[0096] like Figure 4 As shown in this application, TE-PTB allocates page table pages for a new security domain (IOASID) within a trusted enclave and generates the underlying PTE plaintext. Subsequently, TE-PTB requests the page table protection key K bound to the IOASID via ICSM. PT ICSM selects the corresponding K based on IOASID. PT And return to TE-PTB to ensure that the encryption operation is performed under the correct security domain key. This enables the page table construction request and K... PT Obtain.

[0097] Furthermore, the TE-PTB atomically reads the monotonic security version number (Nonce) generated by a monotonically increasing security counter maintained internally by the SE-IOMMU. This Nonce is non-reversible and non-software resettable, ensuring the freshness of page table entries and preventing replay attacks across VMs or security domains.

[0098] Furthermore, page table entries are encrypted. TE-PTB uses K... PT Sensitive fields in the PTE (such as the physical address PA) are encrypted. To ensure the uniqueness of the ciphertext and replay detection, the input to the encryption algorithm includes the Nonce, IOASID, and key PTE metadata.

[0099] Enc(PTE field = Encrypt(K) PT PTE field || Nonce || IOASID || PTE Metadata )

[0100] Among them, Enc(PTE) field The field ) represents the encrypted page table field, primarily containing the target physical address (PA). `Encrypt` indicates a hardware-accelerated encryption algorithm (such as AES-GCM or an equivalent scheme). K PT This indicates that the page table protects the working key. (PTE) field This indicates a sensitive field in the basic PTE. Nonce represents the monotonic security version number (anti-replay). IOASID represents the I / O address space identifier (ensuring multi-tenant isolation). PTE Metadata This indicates PTE permission bits and attribute fields that require encryption to prevent tampering. "||" indicates concatenation.

[0101] Encryption result Enc(PTE) field This will serve as the core encrypted part of the E-PTE.

[0102] Furthermore, TE-PTB calculates the Message Authentication Code (MAC) using K. PT Generate a MAC. The MAC must overwrite the ciphertext, nonce, and context information to ensure integrity and replay resistance.

[0103] MAC = HMAC(K PT Enc(PTE) field ) || Nonce || IOASID || Metadata control )

[0104] Here, HMAC represents the hardware-implemented hash message authentication code function. PTThis indicates the page table protection working key. Enc(PTE) field The ) indicates the encrypted page table sensitive field (ciphertext). Nonce represents the monotonic security version number. IOASID represents the I / O address space identifier. Metadata control This indicates control fields (such as flags) that do not require encryption but need integrity protection.

[0105] MAC covers the ciphertext, nonce, and context identifier to achieve strong consistency verification.

[0106] The MAC will be hardware verified by the SPU module during the IOMMU address translation process.

[0107] E-PTE format encapsulation and writing; TE-PTB will encapsulate Enc(PTE) field The calculated MAC and the current Nonce value are encapsulated into an Enhanced Encrypted Page Table Entry (E-PTE) and written into system memory.

[0108] This application can achieve multi-tenant isolation protection, with each IOASID bound to an independently derived K. PT During the construction process, TE-PTB always uses the K associated with the current IOASID. PT SE-IOMMU performs IOASID-K during the secure translation phase. PT Matching and validation are used to prevent abuse or forgery of page table content across security domains.

[0109] The module interaction process described above is explained below.

[0110] First, TE-PTB and K PT The interaction with the key-binding hardware enables the acquisition of the key corresponding to the current context. PT Binding status, key handle, and non-exportable encryption capabilities. The following is a detailed explanation: When the TE-PTB needs to construct the E-PTE for a specific virtual page, the TE-PTB first sends a key context query request to the ICSM. PT The module compares the current CPU core's execution context, ASID / VMID, Privilege Level, and other hardware binding parameters, and returns K. PT Key Handle, cryptographic access permissions, and the address or access interface of the Nonce field bound to the context. PT The entity never leaves the hardware module in plaintext, nor is it exposed to the software. This interaction ensures that the page table encryption behavior is strictly bound to the virtual machine / process security context.

[0111] Furthermore, the interaction between the TE-PTB and the Nonce hardware enables the injection of a unique, monotonically increasing "freshness" value into the E-PTE. This is explained in detail below: The TE-PTB requests the Nonce corresponding to the current PTE from the Nonce unit through the architecture-defined CSR / IO port. The hardware returns the current count value and updates the counter according to a strategy (e.g., +1, self-update, or on-demand refresh; the preset strategy is a choice of three, a global strategy selected during system design rather than a runtime mixture). This hardware-provided Nonce becomes the input for generating the MAC, effectively providing hardware-level rollback protection.

[0112] It's important to note that the Nonce is not a random number but a verifiable version identifier. Its core function is to bind the time sequence, ensuring that a given E-PTE can only be accepted within its corresponding version window. In the security framework, freshness means whether the current entry is the latest valid version recognized by the system.

[0113] Furthermore, the TE-PTB sends an encryption request to the SPU-CRYPTO encryption module to encrypt the sensitive fields of the PTE and generate a MAC. The details are as follows: The TE-PTB encapsulates the physical address field, permission-related bits, and other security-sensitive fields from the unencrypted PTE data structure into an encrypted input data block (Plain-PTE-Block). The TE-PTB calls the hardware register interface to send a request to the SPU-CRYPTO unit, with the input containing the plaintext PTE data (Plain-PTE-Block), K... PT Handle, Nonce value. SPU-CRYPTO uses an internal hardware key to perform encryption of critical fields (such as using AES-GCM / SM4-CTR) according to a security policy, and generates a Message Authentication Code (MAC). SPU-CRYPTO returns encrypted PTE data (Enc-Fields), a generated Integrity Authentication Code (MAC'), and optional Additional Authentication Data (AAD). The entire process does not expose the key or the encrypted internal state.

[0114] It should be noted that the essential difference between SPU-CRYPTO (Security Processing Unit Cryptographic Engine Module) and PT-Crypto is that SPU-CRYPTO is a hardware computing engine, while PT-Crypto is a functional semantic definition. The page table encryption / decryption module (PT-Crypto) internally calls the SPU-CRYPTO hardware cryptographic engine to perform specific encryption and MAC operations.

[0115] It should be noted that "security policy" does not refer to access control policies in general, but rather to a set of strong constraints on algorithm selection, key lifecycle, nonce management, context binding, failure handling, and key isolation. The SPU-CRYPTO unit performs encryption and integrity authentication operations based on a preset security policy, which includes algorithm mode selection rules, key isolation and derivation rules, nonce management rules, and failure handling rules to ensure the confidentiality, integrity, and replay resistance of page table entries.

[0116] Furthermore, TE-PTB writes the E-PTE back to system memory (untrusted), placing the constructed E-PTE into the page table for subsequent use by the VMM / OS, while maintaining confidentiality and integrity. The specific steps are as follows: TE-PTB combines Enc-Fields + Tags + AADs to form the E-PTE structure. TE-PTB writes this to a page table in Dynamic Random Access Memory (DRAM) (this area is managed by an untrusted hypervisor). Although written to "untrusted memory," the data remains secure under encryption and verification protection.

[0117] Furthermore, the read-only interaction between the Hypervisor / OS and the E-PTE allows untrusted software to read the E-PTE, but prevents it from being tampered with. Specifically, the Hypervisor / OS can only obtain the encrypted form of the E-PTE. If it is tampered with, it will be detected and blocked during the subsequent "DMA / CPU memory access path decryption + MAC verification".

[0118] In this embodiment of the application, when constructing the E-PTE, the TE-PTB uses the page table protection key K derived from and bound to the IOMMU security context. PT The TE-PTB performs encryption operations on sensitive fields through a hardware-accelerated cryptographic module. Simultaneously, the TE-PTB, combined with the monotonic security version number (Nonce) maintained internally by the SE-IOMMU, calculates the Message Authentication Code (MAC) for the page table entry. This MAC is used by the IOMMU hardware during the translation phase for tamper-proofing and anti-replay verification. Finally, the TE-PTB writes the constructed Enhanced Encrypted Page Table Entries (E-PTEs) into system memory. Because the E-PTEs already possess confidentiality, integrity, and freshness protection, the page table contents cannot be stolen, replaced, or replayed even under untrusted VMM or operating system control, ensuring the overall trustworthiness and attack resistance of the I / O address translation path.

[0119] Figure 5 This is a flowchart of an embodiment of the input / output memory management unit page table encryption and integrity protection method according to this application, as follows: Figure 5 As shown, the method includes the following steps:

[0120] S501 obtains the root key from the hardware trusted root, anchors the root key during the system startup phase, and obtains the boot random number.

[0121] S502, obtain the device identifier, perform a key derivation operation based on the root key, device identifier and bootstrap random number, and obtain the input / output memory management unit master key IMK.

[0122] The S503 injects the IMK into the secure key storage module via the on-chip secure bus or interconnect. The secure key storage module includes an unreadable array of secure registers.

[0123] S504, for each security context, performs a key derivation operation based on the context identifier of the security context and the IMK in the security key storage module to obtain the page table protection key. The context identifier includes the virtual machine identifier, IOASID or security environment information.

[0124] S505 binds the page table protection key to the corresponding direct memory access request context index.

[0125] S506, in response to detecting a security context switching event, performs a hardware instantaneous zeroing operation on the page table protection key, deleting the page table protection key.

[0126] The following section details the hardware-based root-trusted K-structure of this application. PT Secure loading, binding, and isolation mechanisms.

[0127] This process is led by the IOMMU Root of Trust and Key Management Unit (ITKU) as an extension of the system-level hardware root of trust (HRoT) chain. It is used to execute page table protection keys (K...) during system startup and security context switching phases. PT Hardware-based secure loading, binding, and management of ).

[0128] like Figure 6 As shown, the hardware anchoring of the root key is first introduced. In this application, the device unique root key (DRK) is stored in an on-chip read-only secure storage module inside the ITKU. This key is provided by the Hardware Trusted Root (HRoT) and is anchored during the system startup phase to ensure that it cannot be read or tampered with.

[0129] Furthermore, the IMK is derived and constructed. The Hardware Key Derivation Module (KDF) within the ITKU performs the key derivation operation, using the DRK, the device's unique identifier (DeviceID), and the boot nonce from the secure boot process as input to generate the IOMMU master key (IMK). The derivation formula is: IMK = KDF(DRK ||DeviceID || Boot_Nonce).

[0130] Furthermore, secure injection of the IMK is performed, whereby the IMK is injected into the Secure Key Storage (SKR) module inside the SE-IOMMU in a non-peepable manner via the Secure On-Chip Interconnect. Hardware mechanisms ensure that this key cannot be debugged or read out by software within the SKR.

[0131] Furthermore, execute domain-level K PT The derivation and binding of the page table protection key (K) involves, for each security context, the ICSM (Context Isolation Mechanism) using the IMK and the unique identifier of that context (such as VMID, IOASID, or Security World information) to derive the page table protection key (K). PT ). The K PT It is bound to the corresponding DMA request context index. K PT Derived formula: K PT =KDF(IMK|| VMID || IOASID).

[0132] Security World refers to a hardware security module (HSM)-based key lifecycle management and security domain architecture.

[0133] Furthermore, hardware key lifecycle management is performed. Specifically, when the IOMMU detects a security context switching event (such as VMID switching or VM / security domain destruction), the ICSM triggers the SKR to update the current key. PT Immediately perform hardware zeroing to ensure no key remains, effectively preventing cross-domain leaks or data residue attacks.

[0134] The following describes the module interaction process for each of the above steps.

[0135] First, let's introduce the interaction between the HRoT and ITKU-DRK storage units: During the device manufacturing phase, the Hardware Root of Trust (HRoT) writes the device-unique root key DRK into the One-Time Fuse (OTP) or Physically Unclonable Structure (PUF) inside the ITKU. This key can only be referenced within the ITKU and cannot be read or exported on the system bus.

[0136] Furthermore, the interaction between the BootROM and KDF modules is described: After the system is powered on, the BootROM will pass the startup random number Boot_Nonce and the device identifier DeviceID to the hardware key derivation module (KDF) inside the ITKU, and request the derivation of the IOMMU master key (IMK).

[0137] Furthermore, the interaction between KDF, DRK storage unit, and KDF itself is described: KDF calls DRK through its internal secure access interface, combining DeviceID and Boot_Nonce to perform cryptographic derivation operations to generate IMK. DRK remains within the secure storage unit throughout the entire process, and the original key is not exposed to external logic.

[0138] Furthermore, the interaction between KDF and SKR (within the SE-IOMMU) is described: the derived IMK is sent to the secure key storage module (SKR) within the SE-IOMMU via an on-chip secure interconnect. The transmission path uses a non-spycat bus protocol, and the transmission register is automatically cleared by hardware after injection is complete.

[0139] Furthermore, the interaction between SKR and ICSM (Security Context Isolation Module) is described: Whenever the IOMMU creates or switches security contexts such as VM-ID / IOASID, ICSM requests SKR to derive the page table protection key K with "IMK and context identifier (VMID / IOASID)" as input. PT SKR completes K internally PT The key is generated and the corresponding key index (Key SlotID) is returned, not the plaintext key. A dedicated working key K is derived for page table encryption and integrity protection. PT .

[0140] Furthermore, the interaction between ICSM and the IOMMU Secure Page Table Protection Engine (SPU) is described: ICSM sends the key slot ID associated with the current context to the SPU. When processing E-PTE decryption and MAC verification, the SPU uses this index to securely reference the corresponding key from the array within the SKR. PT This enables hardware-level key isolation across VMs.

[0141] Furthermore, the SKR itself (zeroing logic) is described. When ICSM detects a context destruction, VM switch, or domain release event (e.g., triggered by an hfence operation instruction executed by the Hypervisor or an IOMMU-specific security barrier instruction), it will issue a key revocation instruction. SKR then performs a hardware-level immediate zeroing operation, deleting the corresponding key. PT This ensures that the key does not remain in any registers or cache.

[0142] The embodiments of this application can ensure hardware isolation of keys in multi-virtual machine and multi-security domain environments, and realize hardware-based security management of key lifecycle (including immediate zeroing).

[0143] Figure 7This is a flowchart of an embodiment of the input / output memory management unit page table encryption and integrity protection method according to this application, as follows: Figure 7 As shown, the method includes the following steps:

[0144] S701, in response to receiving a direct memory access request sent by an external device, extracts a context field from the direct memory access request, the context field including IOASID.

[0145] S702 looks up the page table protection key index based on the IOASID in the context field, loads the hardware key handle of the found page table protection key into the working register through the on-chip secure interconnect, and loads the latest historical monotonic security version number threshold bound to the context into the version number comparator for freshness checking.

[0146] S703 reads the enhanced encrypted entry corresponding to the target page table entry through the memory interface, performs format parsing on its internal fields, and extracts the page table entry content. The page table entry content includes at least the encrypted physical address field, message authentication code, monotonic security version number, and control field.

[0147] S704, in the IOMMU address translation pipeline, performs at least one of the following on the read page table entry content in hardware: integrity verification and target address decryption. It also performs an atomicity security check through a hardware comparator. If the security verification passes, the decrypted page table entry is written to the security cache.

[0148] In some implementations, the integrity authentication code is obtained by calculating the encrypted physical address field, control field, and monotonic security version number in the page table entry content using the loaded page table protection key.

[0149] In some implementations, the encrypted physical address field in the page table entry content is decrypted using the loaded page table protection key to obtain the decrypted physical address field.

[0150] In the embodiments of this application, one of integrity verification and target address decryption can be performed, or both can be performed. When performing two, they can be performed in series or in parallel, and this application does not impose any restrictions on this.

[0151] In some implementations, an atomicity security check is performed via a hardware comparator, including: in response to the integrity authentication code being the same as the message authentication code in the page table entry content, the monotonic security version number in the page table entry content satisfying a monotonically increasing constraint, and the enhanced encryption entry being generated by encryption using a page table protection key bound to the same IOASID as the direct memory access request, then the security verification is determined to have passed.

[0152] In some implementations, if the integrity authentication code does not match the message authentication code in the page table entry content, or the monotonic security version number in the page table entry content does not satisfy the monotonically increasing constraint, or the enhanced encryption entry's non-direct memory access request is encrypted using the same IOASID-bound page table protection key, it is determined that the security verification fails. An unmaskable direct memory access security violation exception is triggered, and the current direct memory access translation pipeline is atomically terminated, blocking access from external devices.

[0153] S705 sends the decrypted physical address field to the backend memory subsystem and continues to process DMA requests.

[0154] S706 performs hardware forced nulling on the hardware key handle and decryption intermediate state in the working register after the translation is completed.

[0155] The following section details the DMA translation, decryption, and integrity verification process for the SPU hardware acceleration in this application.

[0156] This process is entirely hardware-triggered and executed within the SE-IOMMU (Secure Extended IOMMU) hardware address translation pipeline, without the involvement of any untrusted software. For address translation requests initiated by peripheral DMA, SE-IOMMU dynamically injects a key bound to the current DMA context (e.g., PCIeRID, VMID, PASID) via ICSM (Integrity & Context Security Module). PT A key handle is provided, ensuring that the key itself is permanently protected by hardware and cannot be read by software. Here, PCIe RID represents the PCIe route ID; VMID represents the virtual machine ID; and PASID represents the process address space ID.

[0157] In obtaining K PT Following the handle, the SPU (Secure Processing Unit) in the pipeline performs hardware-level decryption and integrity MAC verification on the Enhanced Page Table Entries (E-PTEs) retrieved from memory, and executes a nonce-based monotonically increasing freshness verification. All decryption and integrity verification operations are performed in parallel within the SE-IOMMU pipeline without exposing any intermediate states or key material.

[0158] The following describes the specific steps of the DMA translation, decryption, and integrity verification process for SPU hardware acceleration.

[0159] like Figure 8As shown, firstly, DMA request reception and key loading are performed. After receiving the DMA request initiated by the peripheral, the SE-IOMMU extracts the context fields (such as IOASID / VMID / PCIe RID) from the request. The ICSM then looks up the key based on the IOASID. PT Index, and instruct SKR to put the K PT The hardware key handle is loaded into the working register inside the SPU. The entire loading process is completed via on-chip secure interconnect, and the key itself will not appear in the probeable path. ICSM simultaneously loads the latest historical nonce threshold (LatestNonce) bound to this context into the version number comparator inside the SPU for subsequent freshness checks.

[0160] Further, an E-PTE hardware read is performed. The SPU reads the Enhanced Encrypted Entry (E-PTE) corresponding to the target page table entry through the memory interface, performs format parsing on its internal fields, and extracts at least the following:

[0161] Enc(PA): The encrypted physical address field;

[0162] MAC;

[0163] Nonce: The monotonic security version number written by TE-PTB;

[0164] Metadata: Other control fields (such as permission bits, page size information).

[0165] Furthermore, parallel verification and decryption are performed. The SPU performs the following hardware operations on the E-PTE within a single hardware pipeline:

[0166] (a) Integrity Verification (PT-MAC): Using the loaded K PT Regarding the calculation of MAC' for Enc(PA), Metadata, and Nonce, it should be noted that MAC is the message authentication code calculated by TE-PTB when the page table is created or updated; it is a generation item. MAC', on the other hand, represents the message authentication code recalculated by SPU or PT-MAC during address translation; it is the integrity authentication code and is a verification item.

[0167] (b) Target address decryption (PT-Crypto unit): using K PT Decrypt Enc(PA) in real time to recover PA'.

[0168] Both of the above are executed in parallel stages in the pipeline without introducing additional software intervention.

[0169] Furthermore, an atomicity safety check is performed. The hardware comparator performs the atomicity safety check:

[0170] (a) Integrity verification: MAC' must be equal to the MAC in the E-PTE (otherwise it is considered to have been tampered with).

[0171] (b) Anti-replay verification: Nonce in E-PTE must satisfy the monotonically increasing constraint (i.e., Nonce ≥ latest historical Nonce).

[0172] (c) Context binding verification (to prevent cross-domain replay): The E-PTE must be bound to the same IOASID as the DMA request. PT Generate encrypted; otherwise, reject immediately.

[0173] Any situation that does not meet the requirements will be considered an unauthorized access.

[0174] Furthermore, security violations and blocking are implemented. If any verification fails (MAC mismatch or Nonce not fresh), the SPU immediately triggers an unmaskable DMA security violation exception and atomically terminates the current DMA translation pipeline, blocking peripheral access and preventing abnormal access from being written to memory.

[0175] Further, a security cache update is performed. If all security verifications pass, the SPU writes the decrypted PTE entry into the Secure PT Cache. This cache entry contains PA' (the decrypted physical address), a control field, and K. PT Index (not K) PT The cached entries are defined as follows: (1) the physical entity and (2) security status bits (e.g., IntegrityValid, FreshnessValid). These cached entries are only visible within the hardware and cannot be read or modified by software.

[0176] Further, the translation is completed and zeroing is performed. The decrypted physical address PA' is sent to the backend memory subsystem, and the DMA request continues to be processed normally. That is, the decrypted and verified physical address PA' is sent to the backend memory subsystem, and the IOMMU then initiates the corresponding bus access request according to the standard DMA transaction procedure to complete the actual physical memory read and write operation. In addition, the SPU immediately updates the K in its internal working register after completing the translation. PT The handle and decryption intermediate state are hardware-forced nullified. This process is non-maskable and non-interruptible, ensuring that the key cannot be guessed or probed by side-channels.

[0177] It's important to clarify that "normal processing" refers to the DMA transaction entering the standard bus and memory access flow after address translation is complete. This translation refers to the address translation performed by the IOMMU on the DMA request, not the CPU page table translation. Address translation is an abstract concept, mapping addresses from one address space to another. DMA translation is a specific instance of address translation, specifically the address translation performed by the IOMMU on IOVAs initiated by the device.

[0178] The following describes the module interaction process for each of the above steps.

[0179] First, the context key loading interaction process between ICSM and SKR is introduced.

[0180] When a peripheral device initiates a DMA request, ICSM extracts the IOASID attached to the request and performs the following interaction:

[0181] ICSM queries the corresponding K based on IOASID. PT index.

[0182] ICSM sends a "Load-K" command to SKR. PT -Handle).

[0183] SKR returns the corresponding K based on the index. PT The hardware handle is obtained and transmitted to the SPU via the on-chip secure interconnect.

[0184] Furthermore, the nonce loading interaction process between ICSM and SPU is described. ICSM writes the LatestNonce corresponding to the context into the nonce comparator inside the SPU through a separate control channel.

[0185] Furthermore, the E-PTE data reading and interaction process between the SPU and the memory subsystem is described. The encrypted page table entry E-PTE is transferred from memory to the SPU. The SPU parses it internally and does not output any explicit information to external modules.

[0186] Furthermore, the pipelined parallel interaction process between modules within the SPU is described. The SPU performs hardware-level decryption and integrity verification internally, primarily through three paths, represented as follows:

[0187] (1) PT-Crypto (decryption unit) ←K PT (From SKR). Here, PT-Crypto←SKR belongs to the key path, essentially meaning to obtain the encryption / decryption key; its inputs are Enc(PA) and K. PT The output is PA' (the plaintext of the target physical address).

[0188] (2) PT-MAC (MAC verification unit) ←K PT (From SKR). Among them, PT-MAC←SKR belongs to the key path, which essentially means obtaining the authentication key; its inputs are Enc(PA), Metadata, and Nonce; the output is MAC'.

[0189] (3) Nonce Comparator (Version Comparison Unit) ← ICSM. Nonce Comparator ← ICSM belongs to the state path, essentially meaning to obtain the valid version status. Its inputs are E-PTE.Nonce (from memory) and LatestNonce (from ICSM); the output is the FreshnessValid signal.

[0190] The SPU uses a single-cycle pipeline for execution, in which PT-Crypto, PT-MAC, and Nonce Comparator run in parallel, and the output is processed uniformly by the "SPU Security Aggregator".

[0191] It should be noted that PT-Crypto and PT-MAC rely on SKR's "key supply relationship"; NonceComparator relies on ICSM's "version state supply relationship"; the three are executed in parallel in the pipeline, but they depend on different types of resources.

[0192] Furthermore, the internal signal aggregation and decision-making interaction process of the SPU safety aggregator is introduced.

[0193] The SPU Security Aggregator receives the following signals:

[0194] IntegrityValid = (MAC' == MAC); This signal represents the result of performing an integrity check on MAC' and MAC, determining whether the data is intact.

[0195] FreshnessValid = (Nonce ≥ LatestNonce); This signal indicates that the Nonce and LatestNonce are compared to determine whether the page table entry meets the freshness constraint.

[0196] ContextMatch = (IOASID and K) PT (Bind consistent). This signal indicates consistency between IOASID and K. PT The binding is verified to determine whether the page table protection key used by the current SPU is consistent with the mapping relationship. This signal is used to determine whether the key used for the current address translation belongs to the security context corresponding to the DMA request.

[0197] The aggregation generates two results: SecurePass and SecureFail. SecurePass indicates that all conditions are met; SecureFail indicates that no condition is met. ContextMatch indicates context matching.

[0198] Furthermore, the process of preventing security violations between the SPU and the DMA transaction controller is described. If SecureFail=1, the SPU sends a SecurityViolation exception signal to the IOMMU's DMA transaction controller. The DMA controller immediately blocks the current DMA translation, disallowing access to backend memory. The IOMMU generates a hardware-non-maskable security interrupt to notify the upper-layer trusted software.

[0199] Furthermore, the secure cache write interaction process between SPU and Secure PT Cache is described. If SecurePass = 1, SPU will write PA', Metadata, and K... PT The index and security status bits are written to the Secure PT Cache. The Secure PT Cache controls access to entries, disallowing software from reading or inferring them. Subsequent same-domain DMA requests can directly hit the Secure PT Cache, achieving low-latency access.

[0200] Furthermore, the interaction process between the SPU and SKR regarding the key handle and intermediate state zeroing is described. Upon completion of this translation, the SPU issues a Zeroize instruction to the SKR. The SKR performs hardware-level instantaneous zeroing on all intermediate key states, registers, and buffers related to this operation. The zeroing process is not maskable, not debuggable, and involves no software intervention.

[0201] The "translation" here refers to a Secure DMA Translation Transaction. The completion of this translation can be understood as the completion of the secure resolution phase of a DMA address translation.

[0202] Through the above design, this process achieves low-latency, high-concurrency, full hardware, and context-bound security protection for the DMA address translation path, ensuring that the page table content in untrusted memory still maintains confidentiality, integrity, and non-replayability, effectively preventing DMA replay attacks, cross-domain access forgery, and page table tampering attacks that traditional IOMMU architectures cannot defend against.

[0203] Figure 9 This is a structural block diagram of an input / output memory management unit page table encryption and integrity protection system according to an embodiment of this disclosure, as shown below. Figure 9 As shown, TE-PTB(SW), or Translation-Encrypted Page Table Base (Software), represents the encrypted page table base address (managed by the software side). This base address is maintained by the operating system or security monitoring software to support the encrypted page table architecture. The Central Processing Unit (CPU) (Machine Mode M-Mode / Supervisory Mode S-Mode / Virtual Supervisory Mode VS-Mode) indicates the CPU's configuration or exception handling of the SE-IOMMU under different privilege levels.

[0204] PCIe / DMA Device (GPU / NIC / AI Accel) refers to the external device that initiates the DMA request, including Peripheral Component Interconnect Express (PCIe), DMA-enabled devices (DMADevice), graphics processing units (GPUs), network interface cards (NICs), and AI accelerators (AI Accel).

[0205] The Secure Enhanced IOMMU (SE-IOMMU) is a unit formed by adding page table encryption, integrity verification, and replay protection to the IOMMU.

[0206] The Security Page Table Protection Unit (SPTU) is responsible for the decryption and integrity verification of the E-PTE. Its internal functions include AES-GCM-SIV Decryption, MAC Verification, and Nonce Check.

[0207] PTW / IOTLB (Page Table Walker) is used to perform page table traversal and cache translation results. Here, PTW stands for Page Table Walker and IOTLB stands for I / O Translation Lookaside Buffer.

[0208] DRAM stands for Dynamic Random Access Memory, Off-chip Memory stands for Off-chip Storage, and Encrypted PageTables stands for Encrypted Page Tables.

[0209] ICSM (IOMMU Context Security Isolation Module) refers to the IOMMU context security isolation module, whose functions include key indexing and version number management (K). PT Index / Nonce Manager is used to maintain the latest valid nonces and prevent replay attacks.

[0210] IOMMU Device and Secure Domain refer to the IOMMU device and security domain, respectively.

[0211] like Figure 9 As shown below, the data path and control signals are explained. DMA Request indicates a DMA request; IOVA stands for IO Virtual Address; RW indicates Read / Write; IOASID indicates IO Address Space ID; E-PTE indicates Encrypted Page Table Entry; PTBR stands for Page Table Base Register; index indicates the page table index; Enc(PA) indicates the encrypted physical address; MAC indicates the message authentication code; Nonce indicates the version number / random number; || indicates concatenation; Write Encrypted PTE (AES-GCM-SIV+Fresh Nonce) indicates writing an encrypted page table entry using AES-GCM-SIV and a new version number (Fresh Nonce); Context Parameters indicate context parameters; K PT Handle represents the key page table handle; Enc(PTE) represents the encrypted page table entry;

[0212] The output signals {PA, NonceFresh, AuthOK} are explained below, where PA represents the decrypted physical address; NonceFresh indicates a valid version; AuthOK indicates successful authentication; and E-PTE Fetch Done Signal indicates that the E-PTE read is complete. Decrypted PA / Valid Status indicates the decrypted physical address / valid status.

[0213] Validated PA indicates a valid physical address; Access Rights indicates access permissions; SecureIOTLB Fill indicates filling the secure IOTLB; E-PTE Read Command / Control Signal indicates reading the E-PTE command / control signal. MAC Fail indicates authentication failure; Replay indicates a replay attack; Tamper indicates a tampering attack.

[0214] This application introduces a security enhancement module based on Hardware Root of Trust (HRoT) into the address translation path of the RISC-V IOMMU, which can improve the security of I / O data in RISC-V virtualization and confidential computing environments.

[0215] In this embodiment, sensitive information (such as the target physical address) in the IOMMU page table entry (PTE) is stored in encrypted form in system memory (implemented via E-PTE format) to prevent the page table content from being read back and stolen by untrusted VMM, operating system, or side-channel attacks. This enables dynamic encryption protection of the IOMMU page table.

[0216] In this embodiment, by embedding a MAC in the PTE and integrating the IOMMU Security Control Unit (ISCU) in the IOMMU hardware translation path for low-latency verification, the VMM's tampering, replacement, and replay attacks on the page table are effectively defended. Thus, hardware-level integrity verification of the IOMMU page table can be achieved.

[0217] In this embodiment, a dedicated security key storage module (SKR) is introduced, which stores page table protection keys (K) derived or authenticated based on HRoT. PT The key is bound to an I / O address space identifier (IOASID) or device ID to ensure complete key isolation in multi-virtual machine / multi-TEE tenant environments and to achieve hardware-controlled key lifecycle. This application supports fine-grained multi-security domain key isolation and lifecycle management. The SecureKey Register structure, in conjunction with the enhanced IOMMU, stores page table encryption keys and dynamically selects keys based on the Key Handle in the E-PTE, enabling secure page table decryption and authentication in multi-tenant environments. The SKR (Secure Key Register) can also be understood as a secure key register, a key storage unit located internally in the hardware and not readable externally.

[0218] The ISCU module proposed in this application directly embeds decryption and MAC verification logic into the critical path of the IOMMU address translation pipeline, enabling the security processing to be executed in parallel with page table traversal operations. Under this architecture, E-PTE decryption and integrity authentication do not exist as independent additional stages, but are completed overlapping with PTW memory access, address resolution, and IOTLB filling processes, thereby achieving security verification without increasing the number of address translation pipeline stages. Through this pipeline-level fusion design, this application avoids the context switching and software trap overhead caused by relying on VMM or OS intervention for page table verification, achieving a completely hardware-driven secure address translation process. This mechanism maintains the critical path depth of the IOMMU translation path while ensuring confidentiality, integrity, and replay resistance, meeting the performance requirements of high-speed DMA devices for low latency and high throughput.

[0219] In this embodiment, the mechanism is naturally compatible with RISC-V privileged architectures (such as multi-world M-Mode / S-Mode). The loading and management of page table protection keys are only open to trusted software (such as a security monitor), ensuring consistency of the trust boundary between the I / O path and the CPU-side confidential computing environment. Therefore, natural compatibility with the RISC-V TEE / confidential computing ecosystem can be achieved.

[0220] Through the synergistic effect of the above mechanisms, this system can ensure the confidentiality and integrity of I / O data, making it impossible for VMM, OS, or even unauthorized DMA devices to launch address spoofing, out-of-bounds memory access, or page table replay attacks by modifying page table contents.

[0221] Figure 10 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure.

[0222] like Figure 10 As shown, the electronic device 1000 includes:

[0223] The memory 1001 and the processor 1002 are connected by a bus 1003, which connects different components (including the memory 1001 and the processor 1002). The memory 1001 stores a computer program. When the processor 1002 executes the program, it implements the input / output memory management unit page table encryption and integrity protection method of this disclosure embodiment.

[0224] Bus 1003 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Microchannel Architecture bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0225] Electronic device 1000 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 1000, including volatile and non-volatile media, removable and non-removable media.

[0226] The memory 1001 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1004 and / or cache memory 1005. The electronic device 1000 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 1006 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 10 Not shown; usually referred to as a "hard drive"). Although Figure 10 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 1003 via one or more data media interfaces. Memory 1001 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0227] A program / utility 1008 having a set (at least one) of program modules 1007 may be stored, for example, in memory 1001. Such program modules 1007 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 1007 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0228] Electronic device 1000 can also communicate with one or more external devices 1009 (e.g., keyboard, pointing device, display 1011, etc.), and with one or more devices that enable a user to interact with the electronic device 1000, and / or with any device that enables the electronic device 1000 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 1012. Furthermore, electronic device 1000 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1013. Figure 10 As shown, network adapter 1013 communicates with other modules of electronic device 1000 via bus 1003. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with electronic device 1000, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0229] The processor 1002 performs various functional applications and data processing by running programs stored in the memory 1001.

[0230] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the method for encrypting and protecting the page table of the input / output memory management unit in this disclosure embodiment, and will not be repeated here.

[0231] To implement the above embodiments, this disclosure also proposes a computer-readable storage medium.

[0232] When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the aforementioned input / output memory management unit page table encryption and integrity protection method. Optionally, the computer-readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0233] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the field of this application that are not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0234] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for encrypting and protecting the integrity of page tables in an input / output memory management unit, characterized in that, include: Allocate page table pages for the new security domain input / output address space identifier IOASID, and generate plaintext base page table entries; The corresponding page table protection key is determined based on the security domain IOASID, and the monotonic security version number maintained by the hardware is obtained. The IOASID is bound to the independently derived page table protection key. Based on the page table protection key, the IOASID, and the monotonic security version number, the encryption result and message authentication code are obtained through hardware encryption and integrity calculation of the security-enhanced input / output memory management unit (IOMMU). The encryption result, the message authentication code, and the monotonic security version number are encapsulated into an enhanced encrypted page table entry and written into system memory. The message authentication code includes at least the encryption result, the IOASID, and the monotonic security version number.

2. The method according to claim 1, characterized in that, The step of obtaining the encryption result and message authentication code based on the page table protection key, the IOASID, and the monotonic security version number through security-enhanced IOMMU hardware encryption and integrity calculation includes: The fields in the page table entry are encrypted using the page table protection key, the IOASID, and the monotonic security version number, and the encryption result is obtained. Based on the encryption result, the page table protection key, the IOASID, the monotonic security version number, and the control field, the message authentication code is calculated and generated.

3. The method according to claim 1 or 2, characterized in that, Before allocating page tables for the new security domain IOASID, the process also includes: Obtain the root key from the hardware trusted root, anchor the root key during the system startup phase, and obtain the boot random number; Obtain the device identifier, and perform a key derivation operation based on the root key, the device identifier, and the bootstrap random number to obtain the input / output memory management unit master key IMK; The IMK is injected into the secure key storage module via an on-chip secure bus or interconnect, the secure key storage module including an unreadable secure register array; For each security context, a key derivation operation is performed based on the context identifier of the security context and the IMK in the security key storage module to obtain the page table protection key. The context identifier includes virtual machine identifier, IOASID, or security environment information.

4. The method according to claim 3, characterized in that, Also includes: Bind the page table protection key to the corresponding direct memory access request context index; In response to the detection of a security context switching event, a hardware instantaneous zeroing operation is performed on the page table protection key to delete the page table protection key.

5. The method according to claim 1, characterized in that, Also includes: In response to receiving a direct memory access request from an external device, a context field is extracted from the direct memory access request, the context field including IOASID; The page table protection key index is found based on the IOASID in the context field. The hardware key handle of the found page table protection key is loaded into the working register via on-chip secure interconnect. The latest historical monotonic security version number threshold bound to this context is loaded into the version number comparator for freshness checking. The enhanced encrypted entry corresponding to the target page table entry is read through the memory interface, and its internal fields are parsed to extract the page table entry content. The page table entry content includes at least the encrypted physical address field, message authentication code, monotonic security version number and control field. In the IOMMU address translation pipeline, at least one of integrity verification and target address decryption is performed on the read page table entry content in hardware, and an atomicity security check is performed through a hardware comparator. If the security verification passes, the decrypted page table entry is written into the security cache.

6. The method according to claim 5, characterized in that, Also includes: The decrypted physical address field is sent to the backend memory subsystem, and the DMA request continues to be processed; And / or, After translation is complete, hardware nullification is performed on the hardware key handle and decryption intermediate state in the working register.

7. The method according to claim 5 or 6, characterized in that, The step of performing at least one of the following on the read page table entry content using hardware: integrity verification and target address decryption: The integrity authentication code is obtained by calculating the encrypted physical address field, control field, and monotonic security version number in the page table entry content using the loaded page table protection key; and / or, The encrypted physical address field in the page table entry is decrypted using the loaded page table protection key to obtain the decrypted physical address field.

8. The method according to claim 7, characterized in that, The atomicity safety check performed via a hardware comparator includes: If the integrity authentication code is the same as the message authentication code in the page table entry content, the monotonic security version number in the page table entry content satisfies the monotonically increasing constraint, and the enhanced encryption entry is generated by encryption using the page table protection key bound to the same IOASID as the direct memory access request, then the security verification is deemed successful.

9. The method according to claim 8, characterized in that, Also includes: If the integrity authentication code is different from the message authentication code in the page table entry content, or the monotonic security version number in the page table entry content does not meet the monotonically increasing constraint, or the enhanced encryption entry is not generated by the page table protection key bound to the same IOASID as the direct memory access request, it is determined that the security verification fails. An unmaskable direct memory access security violation exception is triggered, and the current direct memory access translation pipeline is atomically terminated, blocking access to the external device.

10. A system for encrypting and protecting the integrity of page tables in an input / output memory management unit, characterized in that, include: The root of trust and key management unit is used to perform hardware-based secure loading, binding, and management of page table protection keys during system startup and security context switching phases. A security-enhanced input / output memory management unit includes a security key storage module, a page table encryption / decryption module, and a page table integrity detection module, which are used for security key storage, page table encryption / decryption, page table integrity detection, and secure caching of page table entry content; Software component unit used to build encrypted page tables; The input / output memory management unit page table encryption and integrity protection system is further used to implement the method described in any one of claims 1-9.

11. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to execute the instructions to implement the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1-9.

13. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-9.

Images