Memory Isolation and Privilege Restriction-Based Virtual Machine Protection Method

Abstract

Data in multi-tenant cloud environments is increasingly shared across organizations, making strong in-memory isolation a critical requirement. Existing confidential computing mechanisms such as AMD SEV provide hardware-enforced protection, but they require specialized processors and incur non-trivial performance overhead, which limits their deployment in heterogeneous clouds. This paper presents DASPRI, a software-based approach that constructs an isolated execution environment for trusted virtual machines by combining dual address spaces with privilege restriction. DASPRI partitions physical memory into a normal region and an isolated region on NUMA systems, and steers all memory allocations of trusted VMs into the isolated region by monitoring page faults and kernel allocation paths. It further hardens the isolated region by mediating direct and dynamic kernel mappings and by maintaining separate page caches for trusted and normal VMs. Remote attestation is integrated to protect the integrity of metadata used to identify trusted VMs. We implement DASPRI on a HUAWEI Kunpeng AArch64 server running OpenEuler and evaluate it using microbenchmarks and UnixBench. Experimental results show that DASPRI enforces strong memory isolation with less than 5% overhead on basic system operations and only 1.3% degradation in overall host performance.

1. Introduction

With the continuous advancement of technology, the scale of cloud computing has been rapidly expanding, and it is now being applied across various aspects of social life. Governments around the world are increasingly prioritizing cloud computing. In December 2022, China’s State Council released the Strategic Planning Outline for Expanding Domestic Demand [1], emphasizing the acceleration of information infrastructure construction and the promotion of broader and deeper applications of cloud computing. Similarly, in July 2024, the US Office of Management and Budget (OMB) issued guidance [2] aimed at simplifying and expediting the adoption of modern cloud technologies by government agencies.

As the scale of cloud computing continues to grow, ensuring the security of user-uploaded data has become a critical concern. In 2023, the White House released National Cybersecurity Strategy [3], highlighting the need to improve the cybersecurity and resilience of critical infrastructure, including cloud infrastructure.

To enhance the security of virtual machine memory data in cloud environments, researchers and industry vendors have proposed various solutions. Intel’s Software Guard Extensions (SGX) [4] provides a trusted execution environment through CPU instruction extensions, encapsulating sensitive code and data within enclaves to prevent interference from the operating system, thereby significantly enhancing security. However, due to the limited memory available within enclaves, frequent page scheduling increases system overhead when handling large-scale computational tasks in cloud environments. ARM’s TrustZone technology [5] divides system memory into a normal world and a secure world, protecting the memory and cache data within the secure world. However, when deploying a large number of virtual machines, the efficiency of address translation can be adversely affected. Additionally, AMD’s trusted execution environment based on memory encryption protects overall memory data security through hardware encryption, but the frequent encryption and decryption operations introduce additional time overhead.

In summary, these solutions exhibit limitations in isolation flexibility, constrained isolation space, and high-performance overhead. With the growing prevalence of large-scale neural network models in cloud computing, an increasing number of enterprises are uploading models and data to public clouds for training. However, existing memory data protection schemes have proven inadequate for handling large-scale data tasks.

Thus, a solution is needed to construct a trusted environment for virtual machine memory space while ensuring performance, preventing the underlying operating system or other processes from gaining unauthorized access to virtual machine memory data. This paper proposes DASPRI, a software-based approach that enforces physical memory isolation by dividing host physical memory into standard and isolated regions. Ordinary processes or virtual machines can only access the standard region, leaving the isolated region inaccessible. Even if an attacker obtains privileged host-side access (e.g., by exploiting a VM escape vulnerability) and attempts to map or read isolated pages through host memory management interfaces, DASPRI mediates critical allocation and mapping paths to prevent unauthorized access to trusted VM memory. The main contributions of this study are as follows:

1.

Software-enforced physical memory isolation for trusted VMs. We design a NUMA-aware isolation mechanism that allocates trusted VMs from a dedicated isolated physical memory region while keeping normal VMs in the standard region.

2.

Privilege restriction for preventing unauthorized host-side mappings. We harden the isolated region by mediating privileged mapping paths (e.g., direct and dynamic mappings) and by preventing cross-domain sharing through file-backed mappings.

3.

Prototype implementation and evaluation. We implement DASPRI on a real Kunpeng AArch64 server running OpenEuler and evaluate it with microbenchmarks and UnixBench 5.2.1, showing strong isolation with low overhead.

In summary, this work investigates whether a software-only design can provide strong in-memory isolation for trusted VMs in multi-tenant clouds while keeping the performance overhead within an acceptable range.

The remainder of this paper is organized as follows: Section 2 reviews related work. Section 3 introduces the threat model and system architecture. Section 4 presents the detailed design and implementation of DASPRI. Section 5 evaluates security properties and performance. Section 6 concludes the paper.

2. Related Work

Existing memory protection and isolation techniques can be broadly grouped into two lines. The first line relies on hardware-assisted mechanisms, including enclave/TEE designs (e.g., Intel SGX and ARM TrustZone) and confidential virtualization technologies (e.g., AMD SEV and Intel TDX). The second line explores software-based or hybrid approaches that aim to reduce hardware dependence by enforcing isolation through OS/hypervisor mechanisms. In this section, we first review hardware-based solutions and then discuss software or hybrid approaches to highlight the gap addressed by DASPRI.

Intel’s SGX [6,7] technology aims to create a secure execution environment to protect sensitive data. It allows applications to store sensitive data and code within a protected area of memory called an enclave [8], ensuring the confidentiality and integrity of the data. SGX allocates dedicated physical memory regions for the enclave, thereby enhancing data security. However, the memory capacity of SGX is limited, supporting a maximum of 256MB, which is insufficient for virtual machines in cloud environments.

To address this issue, Coppolino et al. [9] proposed the VISE solution in 2020, combining homomorphic encryption with SGX. In VISE, encryption operations are performed inside the SGX enclave, while computations on the ciphertext are carried out outside the enclave using homomorphic encryption techniques. This solution is mainly applied in the industrial cloud domain, where data is transmitted to the cloud via TLS, encrypted within SGX, and then processed externally. Through this combination, VISE alleviates the memory limitations of SGX, but homomorphic encryption still introduces computational overhead.

Compared to the first generation, Intel’s SGX v2 introduces several architectural improvements aimed at enhancing performance [10]. Key enhancements include increasing the enclave memory capacity to 512 GB per processor—scalable to 1 TB on multi-socket systems [11]—as well as supporting security expansion across NUMA nodes and mitigating memory protection overhead. These improvements theoretically address the problems of SGX v1, but research by El-Hindi  et al. [12] indicates that when data exceed the EPC capacity of each NUMA node, performance losses due to the paging mechanism still exist. Thus, despite advances in SGX v2, virtual machine applications in cloud environments continue to face challenges.

In addition to performance challenges, researchers have also explored the security of SGX. For example, Chen et al. [13] found that since the voltage requests from Intel CPUs are unencrypted, attackers can exploit this vulnerability to attack the SGX enclave by controlling the voltage signal, potentially stealing encryption keys. To improve security, Wang et al. [14] suggested using the memory-safe language RUST to write SGX code, but this approach relies on software security and does not fully depend on hardware protection, thus posing some risks.

Compared to Intel’s SGX technology, ARM’s TrustZone [15] has also gained attention in the field of memory protection. TrustZone divides the CPU into two states: the secure world and the normal world. In the normal world, applications cannot access the memory resources of the secure world; however, when the system enters the secure world, the CPU can access and protect the data within it. Although TrustZone offers advantages in data protection, it is limited to ARM architectures, restricting its widespread application in cloud environments.

Due to hardware-assisted isolation protection, TrustZone-based systems [5,16] generally assume the entire trust of the secure world, including trusted applications running in the secure world. However, despite TrustZone ensuring isolation between the secure world and the normal world, there are numerous software-based vulnerabilities that threaten the security of the whole secure world [17,18,19]. To protect the memory security of the secure world in TrustZone, Wan et al. [20] proposed RustTEE. This solution provides a memory-safe development environment for applications in the secure world using the Rust programming language. The solution effectively eliminates memory vulnerabilities in the secure world but does not address the issue of TrustZone being tightly coupled with ARM hardware architecture.

Beyond enclave-style TEEs, confidential virtualization aims to protect VM memory against a potentially untrusted host by moving protection into CPU/firmware-assisted mechanisms. AMD Secure Encrypted Virtualization (SEV) [21] protects a VM by encrypting its memory with a per-VM key managed by the security processor, and encryption/decryption is performed transparently by hardware when data move between DRAM and the CPU. As a result, the host/hypervisor cannot directly read the plaintext of guest memory. However, SEV requires SEV-capable processors and cannot be assumed in heterogeneous cloud environments.

Intel Trust Domain Extensions (TDX) [22] provides confidential VMs through a CPU-managed module that enforces access control on protected memory and CPU state. In addition to memory encryption, TDX uses explicit access control checks to restrict host/hypervisor access to the protected domain. Similar to SEV, TDX relies on specific hardware support and is only available on supported platforms.

In summary, SEV mainly relies on per-VM memory encryption to prevent the host from reading guest memory, while TDX combines memory encryption with CPU-enforced access control on protected domains. Although these technologies provide strong protection, their deployment depends on specific hardware availability. In contrast, DASPRI is hardware-independent and focuses on enforcing physical memory isolation and privileged access restriction through software mechanisms on commodity servers, which is particularly useful for heterogeneous cloud settings.

To resolve the issue of TrustZone being bound to ARM hardware architecture, Seungkyun et al. [23] proposed MyTEE, a solution to build a trusted execution environment through software. This approach prevents the kernel from illegally accessing the memory resources of the secure world by reducing kernel privileges, to some extent freeing the secure world from reliance on TrustZone hardware. However, this solution stores the normal-world page tables in the secure world, leading to frequent transitions from the normal world to the secure world for address translation, which incurs additional time overhead.

Furthermore, Feng et al. [24] proposed a new enclave scheme that supports dynamic memory scaling and protection by adding hardware instructions. Xu et al. [25] proposed protecting process security by dividing a protected process into trusted and untrusted code. However, such solutions require specific hardware support. Li et al. [26] developed critical Linux kernel components using Rust to improve memory data security. However, this solution currently only replaces some components and cannot fully replace the Linux kernel.

In conclusion, while existing hardware-assisted solutions can offer strong isolation, they are often constrained by hardware dependence, deployment availability, or memory-capacity limitations. Software-based approaches reduce such dependence but may introduce extra overhead or require non-trivial system changes. These limitations motivate a hardware-independent method to provide practical VM memory isolation in cloud environments, which is the focus of this work.

3. Materials and Methods

3.1. Threat Model and System Overview

This subsection defines the threat model and terminology used throughout the paper and summarizes DASPRI’s design objectives and overall architecture to provide context for the mechanisms described later.

To clarify the trust boundary, we differentiate two scenarios. (1) Runtime privilege escalation: If an adversary (e.g., escaping from an N-VM) gains host root privileges while the host kernel/hypervisor code integrity remains intact, DASPRI’s privilege restriction is designed for this case and prevents unauthorized mapping/access to ZONE_ISOLATE through host-side mapping interfaces. (2) Offline code tampering: If the host kernel/hypervisor or DASPRI code is arbitrarily patched (e.g., to remove hooks), this violates the static integrity assumption. In our architecture, such tampering is expected to be detected by the integrity verification/attestation mechanism before trusted VMs are launched or secrets are provisioned. Therefore, we do not assume that the hypervisor is trustworthy by default; rather, we rely on integrity verification before use and enforce privilege restriction during runtime.

Trust in the hardware root of trust is a standard axiom in confidential computing architectures. Furthermore, we assume that the cloud management center (CMC) is secure. In realistic public cloud deployments, the CMC (Control Plane) is strictly isolated—both logically and physically—from the compute nodes (Data Plane) and operates under stringent auditing and access controls. Consequently, the probability of an attacker exploiting a multi-tenant compute node hypervisor (e.g., via VM escape) is significantly higher than compromising the centralized CMC. Therefore, DASPRI specifically targets the threat of compute node hypervisor compromise.

3.1.1. Definitions

Definition 1

(Trusted Virtual Machine (T-VM)). Let $E_i^{\mathrm{vm}}=\{E_{i,0},E_{i,1},\dots ,E_{i,m}\}$ denote the critical components of virtual machine i to be launched, and let $B_i^{\mathrm{vm}}=\{B_{i,0},B_{i,1},\dots ,B_{i,m}\}$ denote their expected baseline measurements. Here, i indexes the VM instance and $j\in \{0,\dots ,m\}$ indexes the critical components of VM i. The virtual machine is considered trusted if and only if each component is measured by the hardware root of trust and the resulting measurement values match the baselines:

$$\{H\left(E_{i,0}\right),\dots ,H\left(E_{i,m}\right)\}=\{B_{i,0},\dots ,B_{i,m}\}.$$

(1)

Equivalently,

$$\forall i:\left(\forall j\in \{0,\dots ,m\},H\left(E_{i,j}\right)=B_{i,j}\right)\Rightarrow \mathrm{T}\text{-}{\mathrm{VM}}_i,$$

(2)

where H denotes a collision-resistant hash function.

Furthermore, since this work emphasizes the prevention of unauthorized access by enhancing physical memory isolation, we define the concept of isolation as follows:

Definition 2

(Isolation). For a physical page $p\in ZON{E}_{I}SOLATE$, the page may be mapped only if the accessing entity S is authorized. This is formally expressed as follows:

$$\forall p\in \mathit{ZONE}\_\mathit{ISOLATE}:Access(S,p)\Rightarrow Authorized(S,p)$$

(3)

In DASPRI, $Authorized(S,p)$ is determined by the trusted VM list (TVL) and the enforced host-side allocation/mapping policy.

3.1.2. Design Objectives

DASPRI is designed to address the risk of data leakage in collaborative computing scenarios involving multiple participants. Specifically, it aims to achieve the following three security objectives:

1.

System Integrity. The design must not introduce new attack surfaces, nor should it weaken existing protection mechanisms of the system (including hardware-based mechanisms such as TPM secure boot and processor-level isolation). For example, even if an attacker escalates privileges to the host kernel level by exploiting a system vulnerability, the system kernel remains protected by secure boot enforced by trusted hardware, preventing the host kernel from being replaced.

2.

Isolation. The design must ensure that participant data is stored in physically isolated memory regions, preventing unauthorized access. For instance, even if a remote attacker gains control over an N-VM co-resident with a T-VM on the same host, the attacker must not be able to access T-VM’s memory by leveraging shared hardware resources or privilege escalation attacks.

3.

Low Overhead. While achieving the above two security goals, the system must maintain performance levels comparable to those of a standard system without DASPRI deployment, ensuring the practicality of the solution.

3.1.3. Architecture Overview

While trusted computing technologies can provide users with a verifiable runtime environment, they do not by themselves prevent the leakage of user data during execution. To address this limitation, we propose DASPRI, a virtual machine protection mechanism based on memory isolation and privilege restriction. DASPRI constructs an isolated execution environment for T-VMs to reduce the risk of data leakage.

Figure 1 presents the overall architecture of DASPRI, which comprises two entities and three core modules. Compute nodes host multiple virtual machines to provide basic cloud services, while the cloud management center monitors and manages the lifecycle of both compute nodes and VMs.

The three core modules are defined as follows:

1.

Physical Memory Isolation Module. This module partitions a continuous region of physical memory under the NUMA architecture to serve as a dedicated isolated memory region for T-VMs. It also modifies memory parsing routines to ensure that the isolated region remains available throughout the runtime of compute nodes.

2.

Memory Request Control Module. Implemented inside the kernel, this module intercepts physical memory allocation requests and dispatches them based on the trusted VM list (TVL) maintained on each compute node. Memory requests from normal VMs (N-VMs) are mapped to the standard memory region, whereas requests from T-VMs are directed to the isolated region. The cloud management center uses remote attestation to periodically verify the integrity of the local TVL on each node. In addition, by modifying the page cache mechanism, this module ensures that read-only file-backed pages are mapped separately in the standard and isolated regions, preventing normal processes from reaching the isolated memory via shared read-only mappings.

3.

Privilege Restriction Module. This module enforces access control by modifying the memory mapping logic for both the direct mapping region and the dynamic mapping region. It monitors critical kernel functions to prevent privileged processes from illegally mapping or accessing the contents of the isolated memory region.

3.1.4. Attack Scenarios

In real-world cloud deployments, it is often unavoidable that a trusted virtual machine and a potentially malicious virtual machine share the same physical host. This co-residency creates opportunities for attackers to compromise data confidentiality or integrity. To address these risks, DASPRI introduces enhanced isolation mechanisms and privilege controls, evaluated against three representative threat scenarios.

The first scenario involves co-residency attacks, where an attacker deploys a malicious virtual machine on the same host as the target T-VM. By exploiting virtual machine escape vulnerabilities, the attacker attempts to obtain privileged host-side capabilities (e.g., root or host-kernel-level access) and then extract data from the T-VM through host memory mapping and inspection. DASPRI mitigates such attacks by enforcing physical memory isolation and restricting kernel-level access to protected memory regions, thereby maintaining isolation even under escalated privileges.

In the second scenario, the attacker attempts to forge a trusted virtual machine identity by manipulating VM descriptors and the local T-VM list on the computing node, aiming to bypass isolation controls and access restricted memory. To counter this, DASPRI employs remote attestation techniques to ensure the integrity of T-VM metadata and verify the authenticity of T-VM instances, effectively preventing identity forgery.

The third scenario considers attacks based on Linux’s shared page cache mechanism. In order to optimize file I/O and memory utilization, Linux allows multiple processes to share cached file pages. However, this feature introduces a security risk whereby a compromised N-VM can tamper with cached file data that is later accessed by the T-VM, thereby compromising data availability and integrity. DASPRI resolves this issue by maintaining independent file page caches for T-VMs and N-VMs through dual-address-space mapping, ensuring that malicious VMs cannot affect the memory content consumed by trusted VMs.

Through these scenarios, the effectiveness of DASPRI in mitigating co-residency threats is demonstrated, underscoring its practical value in securing virtualized multi-tenant cloud environments.

To ensure the memory isolation of T-VMs owned by various participants in a cloud environment, DASPRI introduces three core techniques. First, it establishes a dual-address-space physical memory layout that separates regular memory regions from dedicated isolated memory regions. Second, during the T-VM’s launch and runtime, the memory request control module leverages T-VM identification, physical memory allocation, and file page cache management to place all T-VM-related memory content within the isolated memory zone, thereby achieving physical separation from N-VMs. Third, during host execution, DASPRI enhances the security of the isolated execution zone by monitoring critical kernel functions and restricting privileged operations, thereby protecting user data residing within the isolated memory.

3.2. Dual-Address-Space-Based Isolated Execution Zone

In a NUMA (Non-Uniform Memory Access) system, the kernel uses the Zone_type data structure to partition physical memory into multiple zones. Common configurations include ZONE_DMA and ZONE_NORMAL. The former represents low-address physical memory used for direct memory access operations, while the latter corresponds to the main area of memory that can be directly mapped into process address spaces.

This work analyzes the memory zoning mechanism under Linux NUMA and partitions a contiguous block of physical memory from the ZONE_NORMAL region to form a new isolated region called ZONE_ISOLATE. The changes take effect after a system reboot. The physical memory assigned to N-VMs and T-VMs thus resides in logically separated zones, referred to as dual-address-space physical memory. These zones satisfy the following constraint:

$$Z{N}_{original}(m\_pages)=ZN(m\_pages)+ZI(m\_pages)$$

(4)

Here, $m\_pages$ denotes the number of managed physical pages in the region. $Z{N}_{original}$ represents the original ZONE_NORMAL, $ZN$ is the remaining ZONE_NORMAL after memory isolation, and $ZI$ is the newly defined isolated memory zone.

The configuration process for establishing the isolated memory region is illustrated in Figure 2 and proceeds through the following key steps: First, the Linux kernel configuration file (Kconfig) is modified to include two new parameters—ZONE_ISOLATE and ZONE_ISOLATE_SIZE. These parameters enable dynamic control over the activation and size of the isolated memory region according to the security requirements of the trusted execution environment.

The ZONE_ISOLATE parameter is responsible for modifying the Zone_type data structure to declare the existence of the isolated memory region within the system. Simultaneously, the ZONE_ISOLATE_SIZE parameter defines the physical page frame range for this region by adjusting the max_zone_pfns array.

Once these settings are complete, the physical memory isolation module must configure and interpret memory zone masks to distinguish between normal and isolated regions during memory allocation. When a process requests physical memory, the kernel checks the zone mask accompanying the request to determine the target memory region. For this purpose, the memory isolation module defines a custom mask 0x10 for the ZONE_ISOLATE region and modifies the kernel’s zone mask parser to interpret it correctly. If the mask in the request matches the isolated region’s mask, the parser sets the internal zone mask to 0z10. This mask is then processed through a shifting operation, as described in Algorithm 1, to determine the target zone index. When the result corresponds to ZONE_ISOLATE, the system successfully identifies the isolated zone, enabling secure memory allocation for T-VMs.

Algorithm 1 Memory Allocation Mask Parsing Algorithm

Input:  $Gfp\_flag$ Output:  $Zone\_type$ enum $zone\_typez$ int $bit\Leftarrow (\_\_forceint)(gfp\_flag\&GFP\_ZONEMASK)$ if  $gfp\_flag\&Gfp\_ISOLATE$  then     $bit\Leftarrow 0x10u$ end if $z\Leftarrow (Gfp\_ZONE\_TABLE>>(bit\ast Gfp\_ZONES\_SHIFT\left)\right)\&$$\left(\right(1<<Gfp\_ZONES\_SHIFT)-1)$ if  $CONFIG\_MEMORY\_RELIABLE$  then     if z is $ZONE\_MOVABLE\&\&(flags\&GFP\_RELIABLE)$ then         return $ZONE\_NORMAL$;     end if end if return z;

Furthermore, the system configures watermarks (that is, thresholds) for memory resource management and reclamation. These watermarks—minimum (min), low, and high—are fundamental mechanisms in the Linux kernel for maintaining memory balance. The minimum free memory watermark min_free_kbytes must satisfy the following requirement to prevent memory exhaustion and VM crashes:

$$min\_fk\ge \sqrt{ZD(m\_pages)+ZN(m\_pages)+16\ast ZI(m\_pages)}$$

(5)

Here, $min\_fk$ is the value of min_free_kbytes, and $ZD$, $ZN$, and $ZI$ represent the page counts of ZONE_DMA, ZONE_NORMAL, and ZONE_ISOLATE, respectively. The scaling factor 16 is an empirical constant adopted directly from the mainline Linux kernel’s native min_free_kbytes initialization logic. By retaining this upstream heuristic, DASPRI ensures architectural consistency with the standard buddy allocator.

Based on $min\_fk$, the memory isolation watermarks are calculated as follows (using the default configuration of OpenEuler 20.03 LTS SP4):

$$\begin{array}{cc}\hfill min\_watermark& =1\ast min\_fk\hfill \end{array}$$

(6)

$$\begin{array}{cc}\hfill low\_watermark& =1.25\ast min\_fk\hfill \end{array}$$

(7)

$$\begin{array}{cc}\hfill high\_watermark& =1.5\ast min\_fk\hfill \end{array}$$

(8)

When the amount of free memory in the isolated region falls below the low watermark, the kernel invokes the kswapd daemon for asynchronous memory reclamation. If it drops below the high watermark, the system initiates direct page reclamation for both file-backed and anonymous pages, thereby maintaining system stability and ensuring uninterrupted T-VM operations.

3.3. Memory Allocation Control Strategy

After dividing physical memory into normal and isolated regions, the operating system kernel must be able to correctly identify T-VMs to allocate appropriate physical memory according to the TVL. This section provides a detailed explanation of T-VM identification, physical memory allocation, and page cache file page mapping strategies.

3.3.1. Trusted VM Identification Based on Tag Indexing

Trusted VM Tag

In this work, a trusted virtual machine label (Tid) serves as the basis for allocating isolated physical memory to T-VMs, with each T-VM assigned a unique Tid. This label is generated by the cloud management center and implemented as an unsigned long integer variable, embedded into the process control block of the corresponding virtual machine on the compute node. When a participant applies for a T-VM, the cloud management center first generates a UUID and Tid for the virtual machine. It then computes a hash value HUT using Equation (9), and records the UUID, Tid, and computed HUT in the TVL, whose structure is illustrated in Figure 3. Each compute node maintains a local copy of the TVL with an identical structure.

$$HUT=Hash\left(UUID\right|\left|Tid\right)$$

(9)

The consistency comparison timing diagram is illustrated in Figure 4. To prevent replay attacks, the cloud management center generates a random number $n_1$ and computes using the following expression.

$$\begin{array}{cc}\hfill Tid\prime & =HMAC(Tid,n_1),\hfill \end{array}$$

(10)

$$\begin{array}{cc}\hfill M_1& =En{c}_{ke}\left(Tid\right||CreateTVM\_cmd||n_1)\hfill \end{array}$$

(11)

where $k_e$ is a symmetric key and CreateTVM_cmd represents the command to create a T-VM. The encrypted message $M_1$ is sent to the computing node.

Upon receiving $M_1$, the compute node decrypts it using $k_e$ to extract Tid’, Tid, CreateTVM_cmd, and $n_1$. It then verifies the integrity of Tid using Equation (12). If the equation holds, the Tid is considered untampered. The compute node proceeds to create the T-VM and embeds the Tid into the process control block of the virtual machine, as illustrated in Figure 5. If the equation fails, $M_1$ is discarded, and a warning is issued.

$$HMAC(Tid,n_1)=Tid\prime$$

(12)

T-VM Identification

At the time of creation, the host allocates only virtual memory to the VM. When the VM starts running, it triggers page faults to request physical memory. The memory request control module in the host kernel intercepts physical memory allocation requests and identifies whether the request originates from a T-VM based on $Tid$ and the local TVL. Once identified, the module allocates physical memory from the isolated memory region (detailed in Section 3.3.2). There are two possible cases during the identification of $Tid$:

1.

Tid not present in local TVL.

When the T-VM triggers a page fault for the first time, the memory request control module intercepts the memory allocation request but does not find the corresponding $Ti{d}^{\prime }$ and $uui{d}^{\prime }$ in the local TVL. Then, the module initiates an identity confirmation with the cloud management center via the following procedure:

First, the memory isolation control module calculates the following:

$$\begin{array}{cc}\hfill HUT\prime & =Hash(UUID\prime ||Tid\prime ),\hfill \end{array}$$

(13)

$$\begin{array}{cc}\hfill M_2& =(UUID\prime ||Tid\prime ||HUT\prime )\hfill \end{array}$$

(14)

Next, a random number $n_2$ is generated, and the encrypted message $M_3$ is computed using Equation (15). This message is transmitted to the controller using a secure transport protocol. Note that during the initialization phase of the cloud platform, both the cloud controller and each compute node have already exchanged their respective identity public keys: $AI{K}_{pub\_m}$ for the controller and $AI{K}_{pu{b}_{c}n}$ for the compute node.

$$M_3=En{c}_{AI{K}_{pub\_m}}(Sig{(HUT\prime )}_{AI{K}_{pri\_cn}}\left|\right|M_2\left|\right|n_2)$$

(15)

Upon receiving $M_3$, the controller decrypts it using its private key $AI{K}_{pri\_m}$, and verifies the signature using the public key $AI{K}_{pub\_cn}$. It then searches the TVL for a matching entry with $uuid\prime$, $Tid\prime$, and $H\_UT\prime$. If a match is found, the controller returns a confirmation message to the compute node; otherwise, a denial message is returned and an alert is raised.

Finally, after receiving the confirmation from the controller, the compute node adds the T-VM’s information into the local TVL.

2.

Tid present in local TVL.

If the T-VM is not triggering a page fault for the first time, the memory request control module intercepts the memory allocation request and determines whether the request originates from a T-VM using Algorithm 2.

Algorithm 2 Physical Memory Allocation

1: Input: $Task\_struct$, $UUID$, Local $TVL$ 2: Output: Allocated physical page $Page$ 3: $Tid\Leftarrow get\_Tid(Task\_struct)$ 4: if !$Tid$ then 5:     return $allocate\_ZONE\_NORMAL\left(\right)$ 6: end if 7: for each $list$ in $TVL$ do          ▹ Match the process attributes in the TVL 8:     if $check(UUID,Tid,HUT,list)$ then 9:         return $allocate\_ZONE\_ISOLATE\left(\right)$ 10:     end if 11: end for         ▹$Tid$ not found in local TVL, verify with CMC 12: if  $check\_from\_CMC(UUID,Tid,HUT)$  then 13:     return $allocate\_ZONE\_ISOLATE\left(\right)$ 14: else 15:     return NULL 16: end if

Integrity Protection of the TVL

The TVL is essential for ensuring that the compute node can correctly identify the $Tid$. To prevent attackers from forging T-VMs that are mapped to isolated memory regions by maliciously modifying the TVL, DASPRI adopts remote attestation (RA) to periodically verify the integrity of the local TVL on each compute node. By combining time windows and threshold-based T-VM state transitions, DASPRI introduces randomness into the timing of RA execution, thereby increasing the difficulty for attackers to exploit RA intervals to launch attacks.

Specifically, the management center specifies a time window t and a threshold v. Within this time window, once the number of T-VM state transitions on a compute node accumulates to the threshold v, the compute node proactively initiates the RA procedure with the cloud management center. The RA process proceeds as follows:

First, the compute node generates a query message containing its identifier $i{d}_i$ and sends it to the cloud management center.

Upon receiving the query, the cloud management center checks whether $i{d}_i$ exists in its managed compute node list. If it does, a random nonce $n_3$ is returned to the compute node; otherwise, the message is discarded.

After receiving $n_3$, the compute node collects evidence $HVL$, performs a hash operation to obtain $e_i$, and updates the local counter $count$, such that $count=count+1$. Here, $count$ records the number of times the compute node has performed local integrity verification on $HVL$. The compute node then invokes the hardware root of trust to sign $e_i$, producing the signature $\sigma$: $\sigma =Sign{\left(e_i\right)}_{AI{K}_{pri\_cn}}$.

Subsequently, the compute node calculates the message authentication code $e_i^{\prime }$ using Equation (16), and constructs the encrypted attestation report $C_i$ using Equation (17), which is encrypted with the public key of the cloud management center.

$$\begin{array}{cc}\hfill e_i^{\prime }& =HMAC(k_i;e_i|\left|n_3\right),\hfill \end{array}$$

(16)

$$\begin{array}{cc}\hfill C_i& =En{c}_{AI{K}_{pub\_m}}(e_i^{\prime }\left|\right|e_i\left|\right|\sigma \left|\right|TV{L}_i\left|\right|count\left|\right|k_i)\hfill \end{array}$$

(17)

Upon receiving the ciphertext $C_i$, the cloud management center first decrypts it using its private key. It then predicts the expected RA counter $coun{t}^{\prime }$ for compute node $i{d}_i$ by incrementing the last known count. If $count$ equals $coun{t}^{\prime }$, the cloud center verifies the authenticity and integrity of the data by checking the signature $\sigma$ and the MAC $e_i^{\prime }$. If all verifications succeed, $coun{t}^{\prime }$ is updated accordingly.

Next, the cloud management center performs a hash operation on the stored $HV{L}_i^{\prime }$ corresponding to $i{d}_i$ and compares the result with the received $e_i$. If the values match, a remote attestation result $R{A}_i$ is generated to confirm integrity. Otherwise, a detailed item-by-item comparison between the received $HVL$ and the stored $HV{L}_i^{\prime }$ is performed to accurately identify the abnormal virtual machine(s), which can then be subjected to timely control and mitigation.

3.3.2. Physical Memory Allocation

In the Linux kernel, physical memory allocation is managed by the buddy system and the Slub allocator. Within the DASPRI architecture, the memory request control module leverages monitoring points embedded in these existing allocation mechanisms to distinguish between memory requests from N-VM and T-VM, and accordingly assign physical memory regions.

Buddy System

When a process accesses a memory page, it queries the page table using its virtual address to retrieve the corresponding physical address and then accesses the associated physical page. If the process has not yet been allocated the corresponding physical page, a page fault interrupt is triggered, prompting the kernel to allocate a new physical page. When a page fault occurs, the Linux kernel invokes different memory allocation functions depending on the requested memory type, such as _get_free_page, get_zeroed_page, or _get_dma_pages.

For virtual machines, the Stage-2 page table is used to translate guest physical addresses (GPAs) into host physical addresses (HPAs). If the requested GPA has not yet been mapped, an el1_sync exception is raised and handled by the host kernel. Regardless of the entry point—whether it is _get_free_page or el1_sync—the memory allocation process eventually calls the alloc_page function to obtain a physical page.

Thus, the memory request control module monitors the invocation of alloc_page to intercept all physical memory page allocation requests in real time. By analyzing the tag (e.g., Tid) and consulting the locally maintained TVL, the module determines whether the requesting VM is a T-VM. If so, memory pages from the isolated memory region are allocated; otherwise, the request is served from the normal memory region. It is important to note that while this module relies on kernel allocation paths to place data correctly, the confidentiality of the resulting ZONE_ISOLATE is enforced by the privilege restriction module (Section 3.4), which remains effective even if the hypervisor attempts unauthorized access to these pages.

Slub Allocator

For small-scale memory allocations, the Linux kernel utilizes the Slub allocator, which enhances efficiency by pre-allocating physical pages and dividing them into fixed-size memory objects. Within the DASPRI architecture, the memory request control module modifies the Slub allocator to include a Slub cache dedicated to isolated memory regions. It intercepts small memory allocation requests and determines the VM context from which the request originates. Based on this identification, it selects the appropriate memory region—isolated for T-VMs or normal for N-VMs—for allocation.

Through the integration of both mechanisms, the memory request control module effectively enforces memory isolation: physical memory in the isolated region is exclusively allocated to T-VMs, while N-VMs are restricted to accessing only the normal memory region.

3.3.3. Dual-Address-Space Page Cache Construction

When a T-VM initially accesses a shared library code page, the kernel retrieves the corresponding library file from the disk and loads it into the isolated memory region, subsequently mapping it to the virtual address space of the T-VM. However, if an N-VM later accesses the same shared library, the kernel—leveraging the page cache mechanism—will directly map the data already residing in memory (including from the isolated region) into the virtual address space of the N-VM. This behavior undermines the memory isolation by breaking the separation between address spaces and poses a security risk to the integrity of the isolated memory.

Disabling the page cache mechanism would prevent such breaches of isolation but would drastically reduce the performance of file read and write operations. The page cache is managed by the f_mapping field within the file structure, which is of type address_space and represents the current in-memory cache of the file.

To address this issue, DASPRI extends the kernel’s file structure by introducing a union construct. This union retains the original f_mapping field for representing memory access mappings of N-VMs and adds a new field t_f_mapping dedicated to T-VM memory mappings. This design enables the kernel to create independent page caches in the isolated and normal memory regions based on the type of requesting process when file data is loaded into memory, as illustrated in Figure 6.

When a process attempts to read a file, the kernel first determines whether the process originates from a T-VM by checking its tag. If it is a T-VM, the system uses the t_f_mapping page cache; otherwise, the f_mapping cache is used (lines 4–8 in Algorithm 3). The kernel then checks whether the corresponding file page is already cached in memory. If it exists, the page is returned directly; if not, the page cache is created in the corresponding memory region (lines 9–13 in Algorithm 3).

Algorithm 3 Page Cache Creation

1: Input: Struct file 2: Output: Page    ▹ Data structure describing the mapping between file and memory, managing file caching and mapping in memory 3: struct address_space *$mapping$ 4: if is_T_VM($Tid\_list$) then 5:     $mapping\Leftarrow file\to t\_f\_mapping$ 6: else 7:     $mapping\Leftarrow file\to f\_mapping$ 8: end if 9: struct inode *$inode\Leftarrow mapping\to host$ 10: $page\Leftarrow find\_get\_page(mapping,offset)$ 11: if !$page$ then 12:     $page\Leftarrow pagecache\_get\_page(mapping,offset,FGP\_CREAT|$$FGP\_FOR\_MMAP,vmf\to gfp\_mask)$ 13: end if 14: return page

In addition, processes may establish interprocess communication through shared memory mappings of files. To prevent this behavior from compromising the security of the isolated region, the shared mapping mechanism must satisfy the following two properties:

• Isolation of Shared Mappings: The memory request control module intercepts and monitors system calls such as mmap and shm to ensure that shared mappings (including file-backed and anonymous mappings) are restricted within the same memory region. That is, processes in the same memory region may share memory, but processes across different regions are prohibited from doing so.
• Uniqueness of Shared Mappings: DASPRI enforces that a shared mapping for a given file can exist in either the normal memory region or the isolated memory region, but not both. If a shared mapping for a particular disk file already exists in one region, the system will reject any attempt to create a duplicate mapping in the other region.

While our current prototype partitions the physical memory into two primary regions (ZONE_NORMAL and ZONE_ISOLATE), this design choice was made to serve as a foundational proof-of-concept to verify the core feasibility of our software-defined isolation mechanism. The DASPRI architecture is fundamentally extensible. If mutually distrustful groups of trusted VMs require strict physical separation from each other in a complex multi-tenant environment, the system can be adapted to provision multiple distinct isolated memory zones. By further subdividing the NUMA nodes and extending the privilege restriction module’s address tracking, DASPRI can support N isolated zones without altering its core security philosophy.

3.4. Security Reinforcement of the Isolated Execution Region

The Linux system operates under a privilege separation model consisting of user mode and kernel mode. User-mode processes are restricted to accessing their own address space. In the proposed dual-address-space memory isolation mechanism, user-mode processes cannot access or compromise the isolated memory region. However, privileged processes in kernel mode can bypass these protections by mapping the isolated memory into the kernel space using the direct mapping area or dynamic mapping mechanisms, thereby undermining the isolation guarantees.

To address the inability of isolated memory to defend against privileged host processes, DASPRI introduces a kernel-monitoring-based security reinforcement mechanism. This mechanism restricts the privileges of kernel-level processes by intercepting key kernel functions and preventing privileged software on the host from accessing the isolated memory region.

This design has an explicit memory-usage trade-off. If a trusted VM and a normal VM access the same file pages, DASPRI maintains two separate page caches (one in ZONE_ISOLATE and one in the normal region), which may duplicate cached pages for the same file content. We accept this overhead as the cost of preventing cross-domain sharing through file-backed mappings. In practice, the additional memory consumption is bounded by the working set of shared file-backed pages that are accessed by both domains and can be controlled through the size of ZONE_ISOLATE and normal page cache reclamation policies.

3.4.1. Restrictions on the Direct Mapping Area

The direct mapping area in the Linux kernel accelerates address translation by providing a linear mapping between virtual and physical addresses. On 64-bit systems, the Linux kernel reserves 128 TB of virtual address space for the direct mapping area. Given that the physical memory of most modern cloud servers is typically less than 1 TB, the direct mapping region effectively covers all physical memory.

If an attacker gains kernel privileges, they can exploit address translation functions (e.g., lm_to_phys) to locate the physical address of the isolated memory region within the direct mapping area. Then, by retrieving the corresponding page descriptor (page) structure, the attacker can map the physical pages to the kernel space. Once these pages are accessible from the kernel space, the attacker can read or modify the contents, thereby compromising the confidentiality and integrity of the data in the isolated memory.

In Linux kernel version 5.10.0, the translation from a virtual address in the direct mapping area to a physical address is denoted by the following expression:

$$phys\_addr=\left(\right(virt\_addr)\&\sim page\_offset)+phys\_offset$$

(18)

Here, $page\_offset$ denotes the base virtual address of the direct mapping area, and $phys\_offset$ represents the starting physical address of the system memory.

To prevent such attacks, DASPRI disables direct mapping for the isolated memory region. Specifically, the access control module enforces the following:

1.

It first calculates the offset address within the direct mapping area using Equation (19):

$$offset\_addr=(virt\_addr)\&\sim page\_offset$$

(19)

where $virt\_addr$ is the given virtual address and $offset\_addr$ is its corresponding offset.

2.

If $offset\_addr>ZN\_m\_page$, this implies that the offset is mapped to the isolated memory region. In this case, the access control module denies the translation and returns a null address (i.e., 0x00).

3.

If $offset\_addr\le ZN\_m\_page$, this indicates that the memory falls within the normal memory region. In this case, the system allows for the translation and returns the physical address.

Furthermore, the kernel provides several functions that can explicitly map physical pages into the kernel space. DASPRI intercepts and audits these address mapping functions to prevent N-VMs from mapping pages belonging to isolated memory.

Taking the kernel function kmap as an example, it receives a physical page frame descriptor (page) as an argument and maps the corresponding physical page to the virtual space of the kernel for use by the caller. Unlike vmalloc, which can be intercepted during memory allocation, kmap may allow attackers to map already-allocated page frames from T-VMs into the kernel space, allowing unauthorized access to isolated data.

To counter this threat, DASPRI modifies the kmap function by adding monitoring checkpoints. The privilege control module ensures that N-VM processes are prohibited from invoking kmap to map isolated memory pages into the kernel space.

3.4.2. Restrictions on the Dynamic Mapping Area

The kernel space located above the direct mapping area is referred to as the dynamic mapping area. In this region, the kernel primarily uses the vmalloc function to map physical memory. The call flow of vmalloc is illustrated in Figure 7.

It can be observed that during memory allocation, vmalloc still invokes the alloc_pages function and thus cannot bypass the buddy system to allocate physical memory independently. As described in Section 3.3.2, the memory request control module places an interception point within alloc_pages based on the buddy system. Whenever vmalloc triggers a physical memory allocation through alloc_pages, the interception point is activated to examine the process issuing the memory allocation request.

To further ensure that the isolation properties of the secure memory region are preserved, additional interception logic is incorporated within alloc_pages to inspect allocation requests targeting the dynamic mapping area. This mechanism ensures that when the kernel utilizes vmalloc to allocate physical memory, such operations do not compromise the isolation of the secure memory region.

4. Results

Enabling the memory request control module and the privileged function restriction module inevitably introduces overhead to the host operating system. To validate that DASPRI satisfies the design goal of low performance overhead, this section first evaluates the latency introduced by the dual-address-space memory isolation mechanism during memory allocation. Subsequently, we employ LMbench and UnixBench 5.1.2 to assess the overall performance impact of the DASPRI prototype system on the host.

A real cloud platform was constructed using two physical servers based on OpenStack Y version. One server was configured as the cloud management node and the other as a compute node. Both servers are equipped with 2-core HUAWEI Kunpeng 920 5250 CPUs @ 2.60 GHz and a Trusted Platform Control Module (TPCM) for the physical root of trust. Our detailed configuration is shown in

Table 1. Experimental setup.

Item	Configuration
Architecture	Kunpeng AArch64
OS	OpenEuler 22.04
Kernel	Linux 5.10.0
Hypervisor	KVM + QEMU 8.1.2
Total memory	376 GB
VM config	2 vCPU, 2 G memory

below.

4.1. Overhead of Memory Allocation

This subsection evaluates the memory allocation latency before and after deploying DASPRI by requesting physical memory of varying sizes. As shown in Figure 8, the memory allocation time increases with the requested memory size. This trend arises because larger memory allocations require the merging of fragmented memory blocks and updating of page tables to map new physical pages, both of which incur additional overhead.

Despite these factors, there is no significant difference in latency between the original kernel and the kernel with DASPRI enabled. This is because the additional logic introduced by the memory request control module—mainly the VM identification step—incurs negligible overhead compared to the time required for memory merging and page table updates.

4.2. Evaluation of Basic OS Operations

We use LMbench to measure the latency of basic operating system operations before and after deploying DASPRI. The results are summarized in

Table 2. Latency of basic operations in the OS.

Test Item	Original OS (ns)	DASPRI (ns)	Latency Increase (%)
0 K File Creation	10.8	10.9	0.93
0 K File Deletion	7.5181	7.8319	1.51
10 K File Creation	21.1	21.2	0.47
10 K File Deletion	12	12.4	1.67
File Mapping	697	725	4.01
Protection Page Latency	0.272	0.282	3.68
Page Fault Latency	0.3663	0.3829	4.53
File Descriptor Selection	1.249	1.25	0.08

. In the “Latency Increase” column, we observe that file mapping, protection fault latency, and page fault latency are notably affected, with overheads of 4.01%, 3.68%, and 4.53%, respectively.

The primary reason for this overhead lies in the dual-address-space design: each space maintains a separate page cache, and the memory request control module intercepts system calls during page faults to perform additional T-VM identification and isolated physical memory allocation. Nonetheless, DASPRI introduces less than 5% overhead in basic system operations while significantly improving T-VM isolation, demonstrating its practical applicability.

Furthermore, we compare DASPRI against the MyTEE [23] solution by running LMbench on both modified kernels. Specifically, we measure the average latency of nine core system calls across ten iterations. As shown in Figure 9, the maximum latency overhead introduced by MyTEE reaches 23%, whereas DASPRI limits the maximum overhead to 18%. This advantage arises because MyTEE operates in monitoring mode and must emulate critical operations, incurring more time compared to DASPRI’s lightweight interception and decision mechanism.

4.3. Overall Host Performance Overhead

We assess the overall performance overhead introduced by DASPRI on the host system using the UnixBench benchmark suite. Upon completion, UnixBench provides a score for each test item, where higher scores indicate better performance.

To evaluate scalability under high-density multi-tenant scenarios, we concurrently executed application workloads across 1, 2, 4, 8, 16, and 32 active trusted virtual machines. As shown in Figure 10, the comprehensive system scores before and after deploying DASPRI are approximately 1296.4 and 1282.9, respectively, indicating that the overall baseline performance only decreased by about 1.3%. As concurrency scales exponentially, both systems exhibit expected performance declines. At low-to-medium densities (one to eight VMs), DASPRI maintains a slight performance gap, with the overall overhead peaking at approximately 3.8% when running four concurrent virtual machines. The performance gap drastically narrows to less than 0.5% under extreme-high-density workloads (16 and 32 VMs).

To further analyze the reasons for the significant performance degradation when running four virtual machines concurrently, we performed a fine-grained comparison of the results for 12 subtests in this scenario. The results are shown in Figure 11. Pure computational tests (such as Dhrystone and double-precision Whetstone) were almost unaffected, while the performance degradation was mainly concentrated in I/O-intensive tests, especially the File Copy test, where the performance drop exceeded 22%. We believe that this localized degradation is mainly related to the additional management overhead incurred by DASPRI during frequent I/O requests, including the interception and processing of dynamic memory allocation behavior, and the additional work required to maintain the page cache under the dual-address-space mechanism.

Combining the experimental results in Figure 1 and Figure 2, we can further infer that as the number of active virtual machines increases, the main bottleneck of the host machine shifts from DASPRI’s inspection logic to more fundamental physical resource constraints, such as frequent CPU context switching and the significant overhead of standard memory management. Therefore, DASPRI’s relatively fixed interception cost is “diluted” in the overall system latency, resulting in minimal observable additional overhead.

In summary, although DASPRI introduces some local overhead in I/O management, its overall scalability is good, and it does not cause significant system-level performance degradation in high-concurrency cloud environments.

5. Discussion

This section first presents a security analysis to determine whether the proposed method meets the two design objectives of system integrity and memory isolation. Subsequently, we validate the security functionality by simulating various attack scenarios.

5.1. Security Assumptions

DASPRI assumes that the server is equipped with a hardware-based root of trust, the cloud management center is absolutely secure, and the communication network is reliable. All programs running on the host—including firmware, core operating system components, and user-space applications—must be verified through the hardware root of trust. Only those on the whitelist and whose code measurements match the predefined baselines are allowed to load and execute. Similar verification mechanisms have been widely supported in previous studies [27,28] and can be directly applied to DASPRI.

It is further assumed that applications deployed on the computing nodes will not intentionally leak sensitive data and that secure communication with the cloud management center is maintained via SSL-encrypted channels. In addition, attackers are assumed to have no physical access to the servers, making offline physical attacks such as cold boot attacks [29] infeasible. We follow the common assumption that, in today’s cloud environments, software-based attacks are much more prevalent than low-level hardware attacks. Therefore, DASPRI focuses on defense against software attacks. Protection against cache-based side-channel attacks is out of the scope of this paper. However, such attacks are orthogonal to the design of DASPRI and can be mitigated by integrating complementary mechanisms proposed in prior work [30,31].

5.2. Security Analysis

Integrity Analysis: According to Definition 1, during system boot or file loading, the hardware root of trust performs measurement operations on critical components $E_i$, generating a measurement digest $H\left(E_i\right)$. By comparing the digest against a reference value $B_i$, the system determines whether the component is trustworthy. If $H\left(E_i\right)=B_i$ for all components, they are allowed to boot and run; otherwise, any component with $H\left(E_i\right)\ne B_i$ is considered compromised, and an alert is immediately triggered to enforce timely remediation. This mechanism ensures both the integrity and reliability of the system.

Similarly, all three functional modules of DASPRI must undergo strict integrity verification before they are activated. Therefore, the introduction of these modules does not weaken the system’s original defense capabilities, and the proposed method satisfies the first design goal stated in Section 3.4.

Isolation Analysis: In DASPRI, the memory region ZONE_ISOLATE, designated for mapping to T-VMs, is strictly controlled during the mapping process. Specifically, DASPRI monitors and intercepts critical kernel function calls in real time and permits mappings only after evaluating the TVL.

From the user-space perspective, the memory request control module enforces interception of calls to critical functions such as alloc_page. The module evaluates each process (subject) using the TVL and redirects the memory request accordingly, ensuring that unauthorized subjects cannot map memory within ZONE_ISOLATE.

In kernel space, the privilege restriction module intercepts address translation requests targeting the direct mapping area. It inspects the address offset, and if the offset exceeds the bounds of ZONE_NORMAL, the request is denied and a null address is returned. When a privileged process attempts to illegally map secure memory region data into the kernel space, the memory request control module again intercepts the alloc_page call and verifies the requesting process via TVL, thereby preventing unauthorized mappings.

Through this multi-layered defense mechanism, DASPRI effectively prevents both unprivileged user-space processes and privileged kernel-space processes from accessing the isolated memory region without authorization. As shown in Definition 2, DASPRI satisfies the second design goal defined in Section 3.4.

5.3. Security Function Verification

To evaluate whether DASPRI meets the integrity and isolation design goals in practical scenarios, this section analyzes CVEs relevant to the attack scenarios described in Section 3.1.4 and maps them onto the DASPRI architecture.

Table 3. Representative KVM CVEs in the past five years.

Property	Attack Type	CVEs
Integrity	Critical Information Tampering	CVE-2022-25636, CVE-2022-0435
Isolation	Privilege Escalation	CVE-2023-0664, CVE-2023-32314
Isolation	Privilege Escalation	CVE-2022-0185, CVE-2020-14364
Isolation	Shared Memory Mapping	CVE-2022-0847, CVE-2023-52848

summarizes representative CVEs related to security threats in KVM over the past five years. These CVEs primarily aim to gain full control over the N-VM to execute arbitrary code, thereby undermining the security defenses of protected virtual machines and stealing data from T-VMs.

1.

Protection of Critical Information Integrity: As a purely software-based memory management restriction, DASPRI does not encrypt the memory contents or alter CPU cache behaviors. Therefore, it does not inherently mitigate microarchitectural side-channel attacks (e.g., Spectre, Meltdown, or Flush + Reload). Defending against these requires orthogonal hardware patches or compiler-level mitigations.

DASPRI uses the TVL to determine whether a process belongs to a T-VM and allocates memory accordingly. Attackers may exploit vulnerabilities such as CVE-2022-25636 to tamper with the TVL by performing out-of-bounds memory writes. If the attacker succeeds in injecting a forged TVL entry, the system may mistakenly permit access to isolated memory regions. However, according to Definition 1, any tampering with TVL leads to an integrity verification failure, i.e., $H\left(E_{TVL}\right)\ne B_{TVL}$, as illustrated in Figure 12.

Furthermore, as described in Section Integrity Protection of the TVL, DASPRI enhances the randomness of the remote attestation schedule, which increases the difficulty for an attacker to exploit temporal gaps between verifications, thereby further improving the integrity assurance of TVL.

2.

Defense Against Privilege Attacks:Taking CVE-2020-14364 as an example, an attacker can exploit this vulnerability to crash the QEMU process and subsequently execute arbitrary code on the host with QEMU’s privileges. In the DASPRI prototype, we simulate an attack scenario in which an attacker hijacks the N-VM and leverages this CVE to obtain host-level privileges. The attacker then attempts to access T-VM memory data residing on the same host using functions such as kmap.

As illustrated in Figure 13, process A (a T-VM) requests isolated memory pages from the host and writes a repeating string value 0x83 to the allocated physical pages. Without enabling the privilege restriction module, the attacker, via the compromised N-VM process B, successfully reads the data from process A. However, after enabling the privilege restriction module, the same attack attempt fails, indicating that DASPRI effectively blocks unauthorized memory access even in the presence of host-level privilege escalation.

3.

Protection of Shared Memory Data:Using CVE-2022-0847 as an illustrative example, we simulate an attack in which the attacker-controlled N-VM and the T-VM read the same file page from the page cache. As shown in Figure 14, without DASPRI deployed, the attacker exploits this vulnerability to corrupt the page cache content read by the T-VM. Once DASPRI is active, the attacker can no longer access the same file page cache as the T-VM, thereby eliminating this attack vector and protecting the integrity of the shared memory.

Using CVE-2022-0847 as an illustrative example, we simulate an attack in which the attacker-controlled N-VM and the T-VM read the same file page from the page cache. As shown in Figure 14, without DASPRI deployed, the attacker exploits this vulnerability to corrupt the page cache content read by the T-VM. Once DASPRI is active, the attacker can no longer access the same file page cache as the T-VM, thereby eliminating this attack vector and protecting the integrity of the shared memory.

5.4. Comparison with Existing Solutions

This subsection compares the proposed DASPRI architecture with existing confidential computing solutions, as summarized in

Table 4. A comparison of different solutions for confidential computing.

Solution	Arch.	Target	Mem Type	Gran.	Priv. Prot.	Tamper Prot.	Shared Mem Prot.
Intel SGX [6,32]	x86	Process	Static	Page	✓	✓	×
Scalable SGX [33]	x86	Process	Static	Page	✓	✓	×
AMD SEV [21]	x86	VM	Dynamic	Page	×	✓	✓
AMD SEV-SNP [34]	x86	VM	Dynamic	Page	✓	✓	✓
Intel TDX [22]	x86	VM	Dynamic	Page	✓	✓	✓
Power9 PEF [35]	Power	VM	Static	Region	✓	✓	✓
ARM S-EL2 [36]	ARM	VM	Dynamic	Region	✓	✓	✓
ARM CCA [37]	ARM	VM	Dynamic	Page	✓	✓	✓
TWinVisor [38]	ARM	VM	Dynamic	Page	✓	✓	✓
MyTEE [23]	ARM	Process	Static	Region	✓	✓	✓
Panic [25]	ARM	Process	Static	Page	✓	✓	×
DASPRI	x86/ARM	VM	Hybrid a	Region	✓	✓	✓

^a Note: DASPRI utilizes a “Hybrid” memory allocation strategy. The physical boundary of ZONE_ISOLATE is statically partitioned during host boot via NUMA configuration, whereas the allocation of page frames within this zone to specific trusted VMs occurs dynamically at runtime upon page faults.

. Most existing approaches, such as Intel SGX, AMD SEV, Intel TDX, and ARM S-EL2, are designed for specific hardware platforms, primarily based on x86 or ARM architectures. Power9 PEF is based on the Power architecture. In contrast, DASPRI is designed to be architecture-independent and can operate on both x86 and ARM platforms.

In terms of the protection target, Intel SGX, Scalable SGX, and MyTEE focus primarily on process-level protection, whereas other solutions are mainly tailored to virtual machine (VM) isolation. Regarding secure memory capacity, Intel SGX and Scalable SGX are constrained to 128/256 MB and 1 TB, respectively, while other solutions allow flexible memory provisioning based on the host’s physical memory capacity.

Most systems provide page-level memory protection, whereas Power9 PEF and ARM S-EL2 implement region-level protection granularity. Except for AMD SEV, all listed solutions are capable of defending against privileged software attacks, which is critical for maintaining data and code confidentiality. Moreover, all solutions support the protection of critical data against tampering, ensuring strong integrity guarantees.

In the context of shared memory protection, systems such as AMD SEV, Intel TDX, ARM CCA, and TWinVisor offer robust defenses. However, Intel SGX and Panic are less effective in this regard.

In summary, existing confidential computing solutions demonstrate varying strengths and limitations across different dimensions. The proposed DASPRI architecture constructs an isolated execution region for T-VMs within the host’s physical memory. By maintaining a dedicated page cache and monitoring privileged kernel functions, DASPRI enhances virtual machine security without relying on specific hardware platforms, thereby providing a reliable security foundation for protecting user data within T-VMs.

5.5. Limitations

While DASPRI provides robust software-defined memory isolation against typical privilege escalation and memory introspection attacks, we explicitly acknowledge several boundaries and limitations of our current design:

1.

Microarchitectural Side-Channel Attacks: As a purely software-based memory management restriction, DASPRI does not encrypt the memory contents or alter CPU cache behaviors. Therefore, it does not inherently mitigate microarchitectural side-channel attacks (e.g., Spectre, Meltdown, or Flush + Reload). Defending against these requires orthogonal hardware patches or compiler-level mitigations.

2.

Reliance on Kernel Correctness: The security guarantees of DASPRI heavily depend on the correctness and absence of bugs within the privilege restriction module and the modified kernel allocation paths. Any undiscovered vulnerability within our hook implementation could potentially be exploited by an attacker to bypass the isolation.

3.

Physical and Hardware-Level Attacks: DASPRI assumes that the underlying hardware and physical environment are secure. It does not mitigate physical attacks (such as cold boot attacks or malicious DMA devices probing memory) nor does it prevent a fully malicious cloud provider with physical access from extracting data. For absolute protection against physical threats, hardware-assisted memory encryption (e.g., AMD SME/SEV) remains necessary.

Long-term fragmentation in ZONE_ISOLATE. The isolated region is managed by the standard Linux buddy allocator and reclamation mechanisms; thus, fragmentation is handled through the OS’s normal allocation/reclaim/compaction behavior. However, this paper does not include a dedicated long-running evaluation of fragmentation in ZONE_ISOLATE, nor does it quantify how fragmentation may affect allocation success rates or the performance of T-VMs under sustained high memory pressure. Our current experiments mainly validate the feasibility of the isolation mechanism and its immediate overhead. A systematic study of long-term fragmentation behavior and its impact on T-VM performance will be investigated in future work.

6. Conclusions

This paper presents a method for constructing an isolated execution environment based on dual address spaces and privilege restriction, aiming to enhance the isolation of VMs under multi-party collaboration scenarios. The goal is to prevent the leakage or misuse of data assets during use by various parties.

At system startup, an independent region of physical memory is established. During VM process execution, page fault interrupts are intercepted to determine the type of virtual machine. According to a predefined policy, memory data of T-VMs are allocated within the isolated memory region, thereby ensuring that user-space processes are unable to access it.

Furthermore, security of the isolated memory region is reinforced via kernel-level monitoring techniques, which prevent unauthorized mappings by privileged processes. This further strengthens the memory isolation of protected virtual machines.

A prototype system of DASPRI has been implemented on a real server equipped with the HUAWEI Kunpeng AArch64 processor and OpenEuler OS. A series of experiments were conducted to verify the effectiveness and practicality of the proposed approach.

Currently, our approach relies on the default Linux memory reclamation mechanism for managing physical memory page reuse. As part of future work, we plan to design a dedicated memory reclamation mechanism for the isolated region to mitigate potential leakage of physical address information resulting from memory recycling.

Ultimately, this paper successfully demonstrates that VM-level memory isolation with strong security guarantees is achievable purely via software mechanisms. By incurring a minimal performance penalty, DASPRI offers a highly practical and scalable alternative to hardware-specific confidential computing solutions, making it particularly well-suited for deployment in heterogeneous cloud environments.