A memory domain-based isolation method and system for WebAssembly applications
By introducing memory domain abstraction and switching mechanisms into WebAssembly applications, the problem of coarse-grained memory isolation is solved, achieving fine-grained isolation at the module level, improving security and performance, and making it suitable for browser-side, server-side, and multi-tenant cloud computing systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- PEKING UNIV
- Filing Date
- 2026-04-03
- Publication Date
- 2026-06-19
AI Technical Summary
Existing WebAssembly applications suffer from coarse-grained memory isolation and difficulty in balancing isolation mechanisms with performance. In particular, they pose a risk of memory security vulnerabilities spreading in multi-module applications. Furthermore, traditional solutions consume significant resources and incur high context switching overhead.
By introducing memory domain abstraction and establishing a memory domain model at the Wasm runtime, different functional modules are mapped to different memory access domains. Domain-level memory access control and fast switching mechanisms are adopted to achieve memory isolation at the module, library, and function levels. A fault isolation mechanism is also designed to limit the scope of vulnerability impact.
It achieves fine-grained memory isolation, improving the security and performance of WebAssembly applications, reducing the impact of memory security vulnerabilities, and maintaining high performance and compatibility.
Smart Images
Figure CN122241780A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer system architecture and software security technology, specifically relating to memory protection and security isolation technology in the WebAssembly (Wasm) runtime environment. In particular, it presents a high-efficiency memory domain-based isolation method and system for WebAssembly applications. By introducing a memory domain mechanism, it achieves an efficient and composable memory isolation method and system implementation within a process, reducing the impact of vulnerabilities such as memory overflow and information leakage while maintaining operational efficiency. This invention is applicable to browser execution environments, server-side Wasm runtimes, and multi-tenant cloud computing systems. Background Technology
[0002] With the rapid development of cloud computing, the execution environment of applications is gradually evolving from the traditional monolithic process or virtual machine model to a runtime model that emphasizes portability, rapid deployment, and strong isolation capabilities. WebAssembly (Wasm) is a virtual instruction set architecture. Its overall architecture includes the core ISA definition, binary encoding, program semantic definition and execution, and application programming interfaces (WebAssembly APIs) for different embedded environments (such as the Web). As a platform-independent intermediate representation format, it has been widely used in browser-side execution and cloud-native application scenarios due to its good performance characteristics and secure sandbox model.
[0003] The existing Wasm security model primarily relies on linear memory and a restricted instruction set to avoid direct access to host system resources. Wasm applications interact with the outside world through a contiguous linear memory segment, which is managed uniformly by the Wasm runtime and prevents out-of-bounds access through boundary checks. While this model provides basic memory security at the application level, it still has significant shortcomings when facing complex applications and real-world software ecosystems.
[0004] In practical deployments, Wasm applications typically need to integrate multiple functional modules, and may even require the introduction of third-party components or code from different sources. These components may originate from legacy code, which is more prone to memory safety vulnerabilities. While these modules may logically have different trust levels, they often share the same linear memory space under the existing Wasm execution model. If a module has a memory vulnerability, an attacker could exploit it to access or corrupt the entire application's memory state, leading to serious security consequences.
[0005] To enhance isolation capabilities, existing technologies typically employ process-level isolation, virtual machine isolation, or splitting different modules into independent Wasm instances. However, these solutions generally suffer from high resource consumption, high context switching overhead, and high inter-module communication costs, making them unsuitable for building high-performance, fine-grained isolated Wasm applications.
[0006] Furthermore, Wasm's linear memory model differs from the paging virtual memory model relied upon by traditional applications in its memory management approach. Wasm applications typically access linear addresses using offsets, while native applications typically use pointer-page table mappings. The efficiency of passing complex pointers cannot be guaranteed when transferring data across domains.
[0007] Therefore, how to introduce a fine-grained, low-overhead, and composable memory isolation mechanism while maintaining the advantages of Wasm's single-process execution and high performance has become a key problem that urgently needs to be solved in the current technology field. Summary of the Invention
[0008] To address the issues of coarse-grained memory isolation and the difficulty in balancing isolation mechanisms with performance in existing Wasm applications, this invention provides a highly efficient memory domain-based isolation method and system for WebAssembly applications. Without altering Wasm's existing programming model and instruction semantics, it introduces memory domain abstraction into the Wasm runtime, establishing a memory domain model that maps different functional modules to different memory access domains. Through domain-level memory access control and fast switching mechanisms, it achieves module-level, library-level, and function-level memory isolation. In the event of memory corruption or out-of-bounds access, the impact is limited to the corresponding memory domain, thereby significantly improving the overall security of Wasm applications while maintaining near-native execution performance.
[0009] This invention employs an isolation design technique centered on memory domains. Within the same Wasm instance or process, logically independent memory domains are allocated to different code modules or execution contexts. Each memory domain corresponds to a set of controlled memory mapping relationships and access permission rules. When executing different module code, the Wasm runtime activates the corresponding memory domain configuration based on the current execution context. Through this design, this invention achieves an isolation effect similar to multiple address spaces within a process, while avoiding the high overhead associated with process or virtual machine switching.
[0010] The technical solution of this invention is:
[0011] A memory domain-based isolation method for WebAssembly applications, the core of which lies in achieving fine-grained memory isolation in the Wasm runtime through memory domain abstraction and memory domain switching mechanisms, including the following steps:
[0012] 1) Establish a memory domain model and map different functional modules to different memory access domains; introduce a domain-aware memory access inspection mechanism in the Wasm runtime to achieve fine-grained control over memory access;
[0013] The memory domain model is built upon the current Wasm linear memory model, dividing Wasm linear memory into multiple logical sub-regions. Each sub-region is identified as a memory domain, breaking through the limitation of Wasm's single linear memory. Memory domains are logically isolated from each other. By default, code within a memory domain can only access the memory areas belonging to that domain.
[0014] The creation, destruction, and configuration of memory domains are managed by the Wasm runtime. The runtime maintains a memory domain description table to record the starting address, size, access permissions, and module information of each memory domain.
[0015] In the specific implementation of the memory domain model, this invention achieves fine-grained control over memory access by introducing a domain-aware memory access check mechanism into the Wasm runtime. When the Wasm runtime parses and executes memory load or store instructions, it determines the domain affiliation of the target memory address based on the current memory domain information.
[0016] If the target address is within the range that is allowed to be accessed in the current memory domain, the access operation is allowed to continue; otherwise, the runtime will trigger an exception handling process to abort the illegal access.
[0017] 2) Design a memory domain switching mechanism so that Wasm can quickly switch the currently active domain context based on the memory domain to which the call target belongs.
[0018] Furthermore, a controlled sharing mechanism is adopted to establish a controlled sharing window, enabling cross-domain data exchange through explicitly configured shared memory areas;
[0019] To support the execution of different modules in different memory domains, this invention designs an efficient memory domain switching mechanism. At function calls, module calls, or Wasm runtime scheduling points, the Wasm runtime quickly switches the currently active domain context based on the memory domain to which the call target belongs.
[0020] The memory domain switching process involves only a small number of updates to the Wasm runtime state and does not require switching processes or threads, thus keeping the switching overhead to a very low level, making it suitable for high-frequency call scenarios.
[0021] In some application scenarios, different memory domains need to share a small amount of data to complete collaborative work. To address this, this invention introduces a controlled sharing mechanism, establishing a controlled sharing window to achieve cross-domain data exchange through explicitly configured shared memory regions.
[0022] Shared memory regions are allocated uniformly by the Wasm runtime, which limits the set of memory domains that can access these regions. When performing memory access checks, the Wasm runtime also considers the permission configuration of the shared regions, thereby supporting necessary data sharing while ensuring security.
[0023] The fault isolation mechanism is designed to strictly limit the impact of memory safety issues to the memory domain where the problem occurs. When the Wasm runtime detects an illegal memory access, out-of-bounds write, or other violation of memory safety policies (i.e., a fault) within a memory domain, it restricts the handling of the exception to the corresponding memory domain, i.e., fault isolation. The Wasm runtime can then execute fault handling strategies, including terminating execution within that domain, reclaiming its memory resources, or resetting related modules, without affecting the continued operation of other memory domains or the entire Wasm instance.
[0024] Through the above fault isolation mechanism, even if a memory vulnerability exists in a certain module, it is difficult for it to spread to other modules or affect the overall system state.
[0025] In practical implementation, this invention provides a memory domain-based isolation system for WebAssembly applications, comprising: a Wasm execution engine module, a domain management module, a domain switching module, a domain-aware memory management module, and a cross-domain communication and shared window module; wherein:
[0026] The Wasm execution engine module is used to parse, verify, and execute Wasm bytecode, providing capabilities such as instruction scheduling, stack and call management;
[0027] The domain management module is used to create and destroy memory domains, maintain domain description tables, and record domain identifiers, domain page sets, protection attributes, shared window authorization information, etc.
[0028] The domain switching module saves and restores the domain context at function entry and exit points, and updates the permission register state when necessary to ensure that memory visibility during execution conforms to the domain policy.
[0029] The domain-aware memory management module provides a domain-level allocator to maintain independent memory for different domains, ensuring that memory objects are allocated within their respective domains and supporting fast garbage collection.
[0030] The cross-domain communication and shared window module provides a mechanism for allocating, authorizing, and destroying shared buffers, supporting data exchange without violating isolation boundaries.
[0031] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0032] This invention provides a memory domain-based isolation method and system for WebAssembly applications. It achieves fine-grained memory isolation within a single Wasm instance, avoiding the high performance overhead of process-level isolation. By clearly separating the visible memory ranges of different components through memory domains, even if third-party libraries experience memory out-of-bounds access, they cannot easily access core application data and critical states, significantly improving overall system security and reliability. Lightweight permission switching at function call boundaries reduces latency caused by process and thread-level switching and cross-process communication, making it suitable for high-frequency calls and low-latency applications. With memory domains as the core abstraction, the isolation mechanism has good composability, supports configuring isolation policies according to component trust levels, and allows enabling or downgrading capabilities such as shared buffers and security policies as needed, making it suitable for complex applications and real-world software ecosystems. The method requires no modification to the Wasm instruction set and application programming model, exhibiting good compatibility and engineering deployability. Attached Figure Description
[0033] Figure 1 This is a block diagram of the overall structure of the efficient isolation system based on memory domain for WebAssembly applications according to the present invention;
[0034] The system architecture includes modules such as the Wasm execution engine module, domain management module, domain switching module, domain-aware memory management module, cross-domain communication and shared windows, as well as the interaction relationships between these modules.
[0035] Figure 2 This is a schematic diagram of the overall process of the efficient isolation method based on memory domain for WebAssembly applications according to the present invention. The diagram shows the complete process of the method. Detailed Implementation
[0036] The present invention will be further described below with reference to the accompanying drawings and embodiments, but the scope of the invention is not limited in any way.
[0037] This invention provides a memory domain-based isolation method and system for WebAssembly applications. When a Wasm application is loaded and initialized, the Wasm runtime first creates a default memory domain to house the application's core logic code and its linear memory. Subsequently, the Wasm runtime creates corresponding memory domains for different functional modules or third-party components. Upon creation, the Wasm runtime allocates a logical address range to each memory domain and records its identifier, starting address, length, access permissions, and associated module information in a memory domain description table. The access permissions include at least one or more of read, write, and execute permissions.
[0038] The method of the present invention specifically includes the following steps:
[0039] A. In order to implement the memory domain model proposed in this invention, a memory domain manager is established in the Wasm runtime to manage memory domains, create at least one default memory domain in the runtime, and create several isolated memory domains for different components.
[0040] This invention divides linear memory into multiple domain page sets at the page granularity, with page sets from different domains being mutually invisible. The memory domain manager maintains a mapping table of linear page numbers and domain identifiers, implemented using an array. During memory access checks, the Wasm runtime calculates the linear page number based on the target address, queries its domain, and compares it with the currently active domain; if they do not match and the page is not within the authorized shared window, it is determined to be an unauthorized access.
[0041] In practical implementation, the system further configures different hardware protection attributes for different domains. For example, it assigns different protection keys to each domain and maps pages belonging to the same domain to the same protection key in the virtual address space. In this case, memory access checks can be performed by the hardware directly rejecting unauthorized access during load and store instructions, thereby reducing the overhead of software checks.
[0042] To avoid switching permissions via frequent host call interfaces, this invention allows the introduction of a class of lightweight domain switching instructions in the Wasm instruction set extension. These instructions are used to quickly modify permission registers in user space (e.g., update permission bits of protection keys). These instructions are inserted by the Wasm runtime during the loading phase or automatically generated by the compiler backend, and the verification phase ensures that they can only be written to the permission range allowed by the Wasm runtime.
[0043] Meanwhile, to ensure compatibility with the existing Wasm runtime, this invention retains a pure software implementation path: when the host hardware does not support the protection key or the Wasm runtime does not enable hardware acceleration, the domain switching module only updates the domain identifier in the execution context and performs a software check.
[0044] The method for creating and initializing memory domains is as follows:
[0045] A1. Create memory domains, divide Wasm linear memory into multiple sets of domain fragments, and maintain an independent set of access permissions and protection attributes for each memory domain;
[0046] A2. During the loading or compilation phase, bind the memory domain identifier to each Wasm function and insert a domain switching instruction at the function entry point to switch the current memory domain in the execution context;
[0047] A3. Perform access checks in the memory access path during Wasm runtime to ensure that load and store operations can only access the currently active domain and authorized shared areas; out-of-bounds access will trigger an exception.
[0048] A4. When unauthorized access or domain policy violations are detected, the Wasm runtime can execute fault handling policies, including terminating the faulty domain, resetting the faulty domain, revoking domain capabilities, and ensuring the continued availability of other domains and the host system.
[0049] A5. Provide a domain-aware memory allocation and deallocation mechanism in the memory domain to ensure that memory objects in different domains are allocated within the address range of the corresponding domain, and support fast memory checking and reclamation;
[0050] As a preferred option, the memory domain is compatible with the memory management of current operating system processes to ensure compatibility with existing processes;
[0051] B. Memory domain switching mechanism, implemented as follows:
[0052] B1. When a function call is executed across memory domains, a memory domain switching process is triggered, and the domain switching module saves the function information.
[0053] B2. The domain switching module updates the domain identifier in the current execution context and then jumps to the called function, which is executed in the switched memory domain;
[0054] B3. When the called function finishes execution and returns, if the calling function is detected to have a different domain identifier than the current domain, a domain switch is triggered again. The domain switch module restores the previously saved function information, and then the program returns to the calling function to continue execution;
[0055] C. Controlled shared window, implemented as follows:
[0056] C1. The caller requests a shared buffer descriptor within the current domain and writes the data to be transmitted into it;
[0057] C2. The Wasm runtime passes the descriptor to the called domain;
[0058] C3. The called domain reads or writes to the shared buffer during its activation;
[0059] C4. When the call returns, the shared window is reclaimed or its permissions are reduced at runtime, for example, from read-write permissions to read-only or completely invisible.
[0060] In specific implementation, this invention utilizes the above method to implement a high-efficiency isolation system based on memory domains for WebAssembly applications, including: a Wasm execution engine module, a domain management module, a domain switching module, a domain-aware memory management module, and a cross-domain communication and shared window module; wherein:
[0061] The Wasm execution engine module is used to parse, verify, and execute Wasm bytecode, providing capabilities such as instruction scheduling, stack and call management;
[0062] The domain management module is used to create and destroy memory domains, maintain domain description tables, and record domain identifiers, domain page sets, protection attributes, shared window authorization information, etc.
[0063] The domain switching module saves and restores the domain context at function entry and exit points, and updates the permission register state when necessary to ensure that memory visibility during execution conforms to the domain policy.
[0064] The domain-aware memory management module provides a domain-level allocator to maintain independent memory for different domains, ensuring that memory objects are allocated within their respective domains and supporting fast garbage collection.
[0065] The cross-domain communication and shared window module provides a shared buffer allocation, authorization, and destruction mechanism, supporting data exchange without violating isolation boundaries;
[0066] In summary, this invention achieves deployable, configurable, and efficient memory isolation capabilities within the same process by introducing memory domain abstraction, domain memory management mechanisms, and low-overhead domain switching and access control schemes into the Wasm runtime. This technology can significantly reduce the impact of memory security vulnerabilities without changing application development methods, while also balancing performance and compatibility.
[0067] It should be noted that the purpose of disclosing the embodiments is to help further understand the present invention. However, those skilled in the art will understand that various substitutions and modifications are possible without departing from the scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the embodiments, and the scope of protection of the present invention is defined by the scope of the claims.
Claims
1. A memory domain-based isolation method for WebAssembly applications, characterized in that, By introducing memory domain abstraction into WebAssembly, i.e., the Wasm application runtime, a memory domain model is established, mapping different functional modules to different memory access domains; through domain-level memory access control and fast switching mechanisms, memory isolation at the module, library, and function levels is achieved. When memory corruption or out-of-bounds access occurs, the impact is limited to the corresponding memory domain; including: 1) The memory domain model is based on the linear memory model of Wasm, which divides the Wasm linear memory into multiple logical sub-regions and identifies each sub-region as a memory domain. The memory domains are logically isolated from each other. The creation, destruction and configuration of memory domains are managed by the Wasm runtime. A domain-aware memory access check mechanism is introduced into the Wasm runtime. When the Wasm runtime parses and executes memory load or store instructions, it determines the domain affiliation of the target memory address based on the current memory domain information, thereby achieving fine-grained control over memory access. 2) Design a memory domain switching mechanism. At function calls, module calls, or Wasm runtime scheduling points, the Wasm runtime quickly switches the currently active domain context based on the memory domain to which the call target belongs. Memory domain switching does not require switching processes or threads, but only involves updating the state of the Wasm runtime. The design incorporates a fault isolation mechanism. When the Wasm runtime detects an illegal memory access, out-of-bounds write, or other fault within a memory domain, it restricts the exception to the corresponding memory domain for processing, i.e., it isolates the fault and further executes the fault handling strategy without affecting the continued operation of other memory domains and the entire Wasm instance.
2. The memory domain-based isolation method for WebAssembly applications as described in claim 1, characterized in that, Wasm runtime maintains a memory domain description table to record the starting address, size, access permissions, and module information of each memory domain.
3. The memory domain-based isolation method for WebAssembly applications as described in claim 1, characterized in that, The target memory address is determined by its domain affiliation. If the target address is within the range that is allowed to be accessed by the current memory domain, the access operation continues. Otherwise, an exception handling process is triggered at runtime to stop the illegal access, thereby achieving fine-grained control over memory access.
4. The memory domain-based isolation method for WebAssembly applications as described in claim 1, characterized in that, In step 2), a controlled sharing mechanism is further adopted to establish a controlled sharing window, and cross-domain data exchange is realized through explicitly configured shared memory areas.
5. The memory domain-based isolation method for WebAssembly applications as described in claim 4, characterized in that, The shared memory region is specifically allocated uniformly by the Wasm runtime, which limits the set of memory domains that can access the region; when performing memory access checks, the Wasm runtime also considers the permission configuration of the shared region.
6. The memory domain-based isolation method for WebAssembly applications as described in claim 1, characterized in that, The fault handling strategy includes terminating execution in the corresponding memory domain, reclaiming the corresponding memory resources, or resetting the relevant modules.
7. The memory domain-based isolation method for WebAssembly applications as described in claim 1, characterized in that, The implementation methods of memory domain switching mechanisms include: B1. When a function call is executed across memory domains, a memory domain switching process is triggered, and the domain switching module saves the function information. B2. The domain switching module updates the domain identifier in the current execution context and jumps to the called function, which is then executed in the switched memory domain. B3. When the called function finishes execution and returns, if the calling function is detected to be different from the current domain identifier, a domain switch is triggered again; the domain switch module restores the previously saved function information, and then the program returns to the calling function to continue execution.
8. The memory domain-based isolation method for WebAssembly applications as described in claim 7, characterized in that, Methods for implementing controlled shared windows include: C1. The caller requests a shared buffer descriptor within the current domain and writes the data to be transmitted into it; C2. The Wasm runtime passes the descriptor to the called domain; C3. The called domain reads or writes to the shared buffer during its activation; C4. When the call returns, the shared window can be reclaimed or its privileges reduced at runtime.
9. A memory domain-based isolation system for WebAssembly applications implemented using the method described in any one of claims 1 to 8, characterized in that, include: The Wasm execution engine module, domain management module, domain switching module, domain-aware memory management module, and cross-domain communication and shared window module; among which: The Wasm execution engine module is used to parse, verify, and execute Wasm bytecode, and to perform instruction scheduling, stack and call management. The domain management module is used to create and destroy memory domains, maintain domain description tables, and record domain identifiers, domain page sets, protection attributes, and shared window authorization information. The domain switching module saves and restores the domain context and updates the permission register state at function entry and exit points; The domain-aware memory management module provides a domain-level allocator that maintains independent memory for different domains, ensuring that memory objects are allocated within their respective domains and supporting fast garbage collection. The cross-domain communication and shared window module provides a mechanism for allocating, authorizing, and destroying shared buffers, supporting data exchange without violating isolation boundaries.