A method and system for lightweight application distribution and isolated running oriented to end-cloud collaboration
By adopting a three-tier system architecture of WASM and OverlayFS+WASI bridge in the edge-cloud collaboration scenario, the problems of difficult cross-architecture distribution, high resource consumption and slow cold start of traditional application distribution methods are solved, and lightweight and secure application distribution and isolated operation are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- KYLIN CORP
- Filing Date
- 2026-02-24
- Publication Date
- 2026-05-29
AI Technical Summary
In edge-cloud collaboration scenarios, traditional application distribution methods face challenges such as difficulties in cross-architecture distribution, high bandwidth consumption, insufficient storage on edge devices, long cold start times, high resource consumption, and violations of the zero-trust security principle.
WebAssembly (WASM) is adopted as the unified application carrier format. Combined with OverlayFS and WASI bridge, a three-tier system architecture is built to achieve seamless operation and secure isolation of applications on heterogeneous devices.
It achieves unified distribution across cloud platforms, microsecond-level cold start, KB-level package size, and sub-MB-level memory usage, ensuring disk consistency before and after system operation and conforming to immutable system design.
Smart Images
Figure CN121723463B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of edge-cloud collaborative computing and lightweight virtualization, specifically relating to a method and system for lightweight application distribution and isolated operation for edge-cloud collaboration. Background Technology
[0002] With the rapid development of edge computing and cloud-native technologies, edge-cloud collaboration scenarios present new challenges for application distribution. Edge devices (such as IoT gateways, edge servers, and embedded terminals) typically employ immutable operating systems like Fedora Silverblue, SteamOS, and read-only embedded Linux, with their root file system RootFS locked as read-only to ensure absolute system stability and security. Simultaneously, edge devices face resource constraints and heterogeneous architectures (using a mix of different instruction set architectures such as ARM, RISC-V, and x86), posing significant challenges to traditional application distribution methods.
[0003] Traditional native applications rely on host libraries, such as glibc, and cannot run if the version is incompatible or permissions are restricted. Current mainstream solutions use Docker or Flatpak, which solve the dependency problem but introduce massive GB-level image redundancy and second-level cold start overhead. Furthermore, their root-privileged daemon operation violates the zero-trust security principle. In edge-cloud collaborative scenarios, these solutions also face challenges such as difficult cross-architecture distribution, high bandwidth consumption, and insufficient storage on edge devices.
[0004] The industry urgently needs a lightweight solution that simultaneously meets the following requirements: unified cross-device cloud distribution, enabling compilation once in the cloud and execution anywhere on the device, achieving extremely small size (KB level), microsecond-level startup, secure and isolated execution, and maintaining the pure foundation of an immutable system. Summary of the Invention
[0005] The purpose of this invention is to provide a lightweight application distribution and isolated execution method and system for edge-cloud collaboration. Using WebAssembly (WASM) as the unified application carrier format, it achieves seamless application execution on heterogeneous devices through a two-layer projection mechanism. This invention is particularly suitable for edge-side environments with immutable operating systems as the base, while also being compatible with cloud-based containerized deployment scenarios.
[0006] To achieve the above objectives, the technical solution of the present invention is as follows:
[0007] A lightweight application distribution and isolated execution method for edge-cloud collaboration includes:
[0008] S1. Use WASM bytecode as the only format for application distribution. Compile the application into a WASM module in the cloud and then distribute it to the end device.
[0009] S2. At the file level, the end device uses OverlayFS to merge the host's read-only configuration data with the memory temporary file system Tmpfs, mapping it to a virtual file system within the WASM sandbox. At the symbol level, a dynamic WASI bridge is introduced to inject the host system's native capabilities into the WASM runtime in real time as host functions, based on the import requirements of the WASM module, thus adapting to the heterogeneous hardware characteristics of the end device.
[0010] Furthermore, in step S2, the system architecture of the end-side device is set to three layers, including: an immutable host layer, a capability bridging layer, and a WASM sandbox layer; the immutable host layer serves as the physical base, with its root file system mounted in read-only mode and merged with OverlayFS and Tmpfs; the capability bridging layer runs in user space, and through the OverlayFS controller, WASI bridge, capability mapping table that records the set of host function requirements in the WASM module, and the daemon process responsible for executing the application, it parses the WASM module requirements and dynamically constructs restricted system call channels; the WASM sandbox layer carries the application, and all its external interactions are relayed through the capability bridging layer.
[0011] Furthermore, the processing flow of the end-side equipment includes:
[0012] S201, Application Loading Phase: When the terminal device receives the WASM module distributed from the cloud, it first calculates the composite fingerprint of the WASM module during loading via the daemon process, and queries the local AOT compilation cache. If the cache is hit and the fingerprint verification passes, the local machine code in the AOT compilation cache is loaded directly to achieve microsecond-level startup; if it is not hit, just-in-time compilation or AOT compilation followed by caching of compilation artifacts is performed to accelerate subsequent calls.
[0013] S202, Runtime Initialization Phase: A zero-copy file system projection is constructed through OverlayFS, with the host read-only directory as the lower layer and Tmpfs as the upper layer, forming a virtual file system for the WASM sandbox; the WASM module imports segments to extract the capability requirement list, and initializes the capability mapping table in memory according to the capability requirement list;
[0014] S203, Request Processing Phase: When the WASM module calls a host function for the first time, the WASI bridge intercepts the call, queries the capability mapping table, and performs pointer conversion, boundary checks, and permission verification before establishing a binding relationship with the host function and caching it; subsequent calls to the same interface directly hit the cache.
[0015] S204, Dynamic Response Phase: When the host system undergoes a capability change, the daemon process queries the capability mapping table and sends a targeted failure notification to the affected WASM instance. After receiving the failure notification, the WASM instance adds an invalid tag to the corresponding entry. The cached entry marked as invalid triggers rebinding on the next call. If the capability has been revoked, an error code is returned.
[0016] S205, Instance Destruction Phase: Based on the configured sandbox granularity, the system triggers the atomic destruction process at the appropriate time, terminating WASM execution, releasing linear memory, and unloading OverlayFS in reverse order according to the principle of reverse dependency. After destruction is completed, the host disk remains consistent before and after operation.
[0017] Preferably, the capability mapping table adopts a two-level index structure: the first level is the WASM module name hash, and the second level is the function name hash; each table entry contains a function signature hash, a host function pointer, a permission bitmap, and a call counter; wherein the call counter is used for anomaly detection.
[0018] Preferably, when the WASM module is loaded for the first time in step S201, it is AOT compiled at runtime to translate the bytecode into the native machine code of the target platform; after compilation, the unique fingerprint of the WASM module is calculated: take the first few bits of the SHA-256 hash value of the binary content of the WASM module, concatenate the compiler version number and the target architecture identifier to form a composite fingerprint, and store the compilation product (machine code) in the cache directory with the fingerprint as the file name.
[0019] Preferably, step S202, which involves constructing a zero-copy file system projection using OverlayFS, includes: employing OverlayFS joint mounting technology, setting the host read-only directory as the lower layer and the memory temporary file system Tmpfs as the upper layer, and merging the two to map a pre-open directory of the WASM sandbox; application read operations are directly passed through to the lower read-only layer to achieve zero copy; write operations trigger copy-on-write, and new data is stored only in the upper memory layer; a volatile flag is set during mounting to ensure that upper layer data is not persisted; when the WASM instance is destroyed, OverlayFS is automatically unloaded and Tmpfs is released.
[0020] Preferably, in step S202, the WASM sandbox setting includes a configurable granular instantaneous sandbox mechanism, including a request-level sandbox and a session-level sandbox; the request-level sandbox is destroyed immediately after processing a single request, and the session-level sandbox is bound to the user session and is destroyed uniformly when the session ends; the sandbox granularity is configured through startup parameters.
[0021] Preferably, the execution flow of the WASI bridge in step S203 includes: when the WASM module calls the host function, the WASI bridge first performs pointer conversion, converting the offset in WASM memory into the virtual address of the host process; then it performs boundary checks to verify that the address does not exceed the allocated memory range; next, it performs permission checks, checking whether the call is allowed based on the permission bitmap in the capability mapping table; then it executes primitive calls, calling the host native function; finally, it writes the return value back to WASM memory.
[0022] In another aspect, this invention proposes a lightweight application distribution and isolation system for edge-cloud collaboration, comprising:
[0023] Cloud-based compilation and distribution module: It uses WASM bytecode as the only format for application distribution, compiles the application into a WASM module in the cloud, and then distributes it to the end devices;
[0024] End-side device module: At the file level, OverlayFS is used to merge the host read-only configuration data with the memory temporary file system Tmpfs and map it to a virtual file system within the WASM sandbox; at the symbol level, a dynamic WASI bridge is introduced to inject the host system's native capabilities into the WASM runtime in real time as host functions according to the import requirements of the WASM module, thus adapting to the heterogeneous hardware characteristics of the end-side device.
[0025] Furthermore, the edge device module includes: an immutable host layer, a capability bridging layer, and a WASM sandbox layer;
[0026] The immutable host layer serves as the physical base, with its root file system mounted in read-only mode and merged with OverlayFS and Tmpfs.
[0027] The capability bridging layer runs in user space. Through the OverlayFS controller, WASI bridge, capability mapping table that records the set of host function requirements in the WASM module, and daemon process responsible for executing the application, it parses the requirements of the WASM module and dynamically builds restricted system call channels.
[0028] The WASM sandbox layer hosts the application, and all its external interactions are relayed through the capability bridging layer.
[0029] Compared with the prior art, the present invention has the following significant advantages:
[0030] Cold start time: Traditional container solutions (such as Docker and Flatpak) require image decompression and runtime initialization, with cold start times typically in the order of seconds. This invention directly loads the WASM module and performs on-demand binding, skipping the image decompression process, and compresses the startup time to the order of milliseconds. Combined with the AOT compilation caching mechanism, repeated startup scenarios can be further optimized to the order of microseconds, providing a performance advantage of two orders of magnitude compared to container solutions.
[0031] Distribution package size: Traditional container images typically contain a complete operating system layer and dependency libraries, with a size ranging from tens to hundreds of MB. This invention uses platform-independent WASM bytecode, containing only the application logic itself, with a size typically ranging from KB to MB, achieving a two-order-of-magnitude compression effect compared to container solutions.
[0032] Runtime memory footprint: Traditional containers require maintaining an independent file system view and process space for each instance, with basic memory overhead in the MB range. The WASM sandbox of this invention only needs to maintain linear memory and a capability cache table, and the basic overhead can be controlled in the sub-MB range, significantly reducing the resource pressure on edge devices.
[0033] Zero Residual Guarantee: This invention combines OverlayFS and TmpFS, ensuring that all runtime-generated data is stored in memory, resulting in zero writes to the host disk during application execution. After application exit, the system automatically unmounts the mount point and releases memory, maintaining bit-level consistency on the host system disk before and after execution, verifiable via hash verification. Attached Figure Description
[0034] Figure 1 This is a flowchart of the end-side device processing in Embodiment 1 of the present invention;
[0035] Figure 2 This is a three-layer system architecture diagram of the end-side device in Embodiment 1 of the present invention;
[0036] Figure 3 This is a timing diagram of on-demand binding in Embodiment 2 of the present invention;
[0037] Figure 4 This is a diagram of the OverlayFS projection mechanism in Embodiment 2 of the present invention;
[0038] Figure 5 This is a lifecycle state diagram of the sandbox in Embodiment 2 of the present invention;
[0039] Figure 6 This is a flowchart illustrating the cache invalidation process in Embodiment 2 of the present invention;
[0040] Figure 7 This is a flowchart of the AOT caching and fingerprint verification process in Embodiment 2 of the present invention. Detailed Implementation
[0041] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.
[0042] The design concept of this invention is to use WASM as a unified application carrier format between edge devices and cloud services. By dynamically constructing a WASI (WebAssemblySystemInterface) adaptation layer, it enables applications to be compiled once, run anywhere, and executed securely and in isolation between the edge and the cloud.
[0043] The present invention will now be described in detail with reference to specific embodiments and accompanying drawings.
[0044] Example 1:
[0045] The lightweight application distribution and isolated execution method for edge-cloud collaboration proposed in Example 1 firstly standardizes the carrier. It adopts platform-independent WASM bytecode as the sole format for application distribution, eliminating the physical dependence on the host CPU architecture (x86, ARM, RISC-V) and OS library version from the source. This achieves a unified distribution mode of cloud compilation and edge execution, that is, the application is compiled into a WASM module in the cloud and then distributed to edge devices.
[0046] Secondly, there's capability projection. At the file level, the edge device utilizes OverlayFS technology to merge the host's read-only configuration data with the in-memory temporary file system Tmpfs, mapping it to a virtual file system within the WASM sandbox. The WASM sandbox is an isolated execution environment tailored for the WASM module on the edge device, serving as the sole secure runtime environment for the WASM module and WASM instances created based on it. At the symbol level, a dynamic WASI bridge is introduced. This dynamic WASI bridge contains no static libraries; instead, it injects the host system's native capabilities (such as network sockets, hardware acceleration interfaces, and sensor APIs) into the WASM runtime in real-time as host functions, adapting to the heterogeneous hardware characteristics of the edge device, based on the requirements of the WASM module's import section.
[0047] Based on the aforementioned capability projection requirements, the system architecture of the edge devices is set to three layers, such as... Figure 2As shown, it includes: an immutable host layer, a capability bridging layer, and a WASM sandbox layer; the immutable host layer serves as the physical base, with its root file system mounted in read-only mode, utilizing OverlayFS and Tmpfs for merging; the capability bridging layer runs in user space, using the OverlayFS controller, WASI bridge, capability mapping table recording the host function requirement set in the WASM module, and the daemon responsible for executing the application to parse the WASM module requirements and dynamically construct restricted system call channels; the WASM sandbox layer hosts the application, and all its external interactions are relayed through the capability bridging layer.
[0048] Based on the above system architecture, the processing flow of the edge device covers five core stages: application loading, runtime initialization, request processing, dynamic response, and instance destruction. These stages are closely interconnected and together constitute the application execution system. For example... Figure 1 As shown, it specifically includes:
[0049] 1. Application Loading Phase: The application loading phase is the starting point of the entire process. When the edge device receives the WASM module distributed from the cloud, it first calculates the composite fingerprint of the WASM module during loading via the daemon process and checks if there is a corresponding compiled local machine code in the local AOT compilation cache. If the cache is hit and the fingerprint verification passes, the local machine code is directly loaded, achieving microsecond-level startup; if not, just-in-time compilation or AOT compilation is performed, and a WASM instance is generated after compilation. At the same time, the compilation artifacts are cached after compilation to accelerate subsequent calls.
[0050] 2. Runtime Initialization Phase: The runtime initialization phase prepares the isolated environment for application execution. The system first constructs a zero-copy file system projection using OverlayFS technology: a virtual file system is formed by mounting the host read-only directory as the lower layer and the in-memory Tmpfs as the upper layer, creating a WASM sandbox. Next, the system scans the WASM module to import segments, extracts the capability requirement list, and initializes the capability mapping table in memory. This phase employs an on-demand binding strategy, only recording capability requirements without performing actual binding, significantly reducing initialization time.
[0051] 3. Request Processing Phase: The request processing phase is the core runtime state of the system. When a WASM module calls a host function for the first time, the WASI bridge intercepts the call, queries the capability mapping table, performs pointer conversion, boundary checks, and permission verification, establishes a binding relationship, and caches the data. Subsequent calls to the same interface directly hit the cache, achieving efficient execution. The WASI bridge completes the entire process in user space, and permission checks and primitive calls are performed atomically, preventing TOCTOU security vulnerabilities.
[0052] 4. Dynamic Response Phase: The dynamic response phase handles runtime capability change events. When a capability change occurs in the host system (such as network disabling or permission updates), the daemon queries the capability mapping table and sends targeted failure notifications to the affected WASM instances. Upon receiving the failure notification, the WASM instance adds an invalid tag to the corresponding entry. The cached entry marked as invalid triggers rebinding on the next call. If the capability has been revoked, an error code is returned for graceful application degradation.
[0053] 5. Instance Destruction Phase: The instance destruction phase ensures zero-residue exit. Based on the configured sandbox granularity (request-level or session-level), the system triggers an atomic destruction process at the appropriate time: terminating WASM execution sequentially according to the reverse dependency principle, releasing linear memory, and unloading OverlayFS. After destruction, the host disk remains consistent before and after operation.
[0054] The solution in this embodiment achieves absolute zero intrusion. The sandbox feature of WASM, combined with the memory overlay mechanism of this solution, ensures zero writes to the host disk during application execution, perfectly aligning with the design philosophy of immutable systems.
[0055] The solution in this embodiment also achieves microsecond-level startup. By eliminating the container image decompression process, it directly loads a KB-level WASM module and completes HostFunction binding, resulting in an order-of-magnitude improvement in startup speed compared to traditional containers.
[0056] Example 2:
[0057] This embodiment is a further explanation of the lightweight application distribution and isolated operation method for end-to-cloud collaboration described in this invention, based on Embodiment 1.
[0058] Based on the system architecture and processing flow of the end-side device described in Embodiment 1, this embodiment is configured as follows:
[0059] I. Capability Mapping Table and On-Demand Binding:
[0060] Traditional WASM runtimes bind all WASI interfaces at once during module instantiation. This invention employs an on-demand binding strategy, a significant departure from this approach.
[0061] When the daemon loads the WASM module, it first scans the import section of the module header to extract the list of capability requirements declared by the application. The system maintains a capability mapping table in memory, which uses a two-level index structure: the first level is the hash of the WASM module name (e.g., wasi_snapshot_preview1), and the second level is the hash of the function name. The system uses the FNV-1a hash algorithm to hash the function signature, ensuring an O(1) query complexity. Each table entry contains four fields: function signature hash (64-bit), host function pointer (64-bit), permission bitmap (32-bit), and call counter (32-bit). The call counter is used for anomaly detection—if the call frequency of a single interface increases abnormally, the system can trigger an alarm or automatically reduce privileges.
[0062] The key point is that the binding operation is delayed until the first call. For example... Figure 3 As shown, when the WASM module (WASM application) calls a host function (e.g., fd_write() in the diagram) for the first time in step 1, the WASI bridge intercepts the call, queries the function signature hash through the capability mapping table, returns the host function pointer, obtains the host function address, and verifies the permission bitmap, establishes a binding relationship, and caches it. Subsequent calls directly hit the cache, without repeating the verification process of steps 2-4.
[0063] Binding caching uses instance-level scope, meaning each WASM instance maintains an independent cache table, and the cache becomes invalid when the instance is destroyed. If a capability change event occurs in the host system (such as disabling a network interface or updating permission policies), the daemon broadcasts a cache invalidation notification to all active instances. Affected cache entries are marked as invalid, and binding verification is re-executed on the next call. This mechanism ensures the security semantics of dynamic capability revocation.
[0064] This mechanism brings two benefits: first, it reduces startup time, as unused interfaces have no binding overhead; second, it narrows the attack surface, as dangerous interfaces that are not actually used are never exposed to the application.
[0065] II. Zero-copy file system projection:
[0066] To enable WASM applications to access host configuration files while ensuring immutability, this invention employs OverlayFS to implement zero-copy file system projection, such as... Figure 4 As shown:
[0067] The system sets the host read-only directory as the lower-level LowerDir and the memory temporary file system Tmpfs as the upper-level UpperDir. After merging the two, they are mapped to a pre-open directory in the WASM sandbox. Application read operations are directly passed through to the read-only layer, achieving zero copy; write operations trigger copy-on-write, and new data is stored only in the upper memory layer.
[0068] Setting the volatile flag during mounting ensures that upper-layer data is not persisted. When the WASM instance is destroyed, the system automatically unloads OverlayFS and releases Tmpfs, leaving no residue on the host disk.
[0069] III. Configurable granularity instantaneous sandbox:
[0070] Traditional containers and virtual machines typically have lifecycles bound to processes or services, with fixed granularity. This invention proposes a configurable, transient sandbox mechanism, including request-level and session-level sandboxes, dynamically selecting the sandbox lifecycle based on the application scenario. Figure 5 The diagram shows the sandbox lifecycle state, illustrating the complete state transition from WASM module loading to atomic destruction, as well as the two destruction trigger times: request-level and session-level.
[0071] Request-level sandboxes are destroyed immediately after processing a single request, making them suitable for Serverless function computing scenarios. Each call obtains a completely isolated execution environment, completely eliminating the risk of state leakage between requests. The system optimizes the sandbox creation path for this purpose, achieving millisecond-level reconstruction through pre-warmed module caching.
[0072] Session-level sandboxes are bound to user sessions and destroyed uniformly when the session ends. They are suitable for interactive application scenarios, allowing temporary states (such as cache and configuration) to be maintained during the session, while ensuring that no trace is left after the user logs out.
[0073] The sandbox granularity is configured through startup parameters, and the bridging layer determines when to trigger the destruction process based on this configuration. Regardless of the granularity used, the destruction action is an atomic operation and follows the reverse dependency principle: the destruction order is strictly the reverse of the creation order. During creation, the following steps are executed sequentially: mounting OverlayFS, initializing linear memory, and loading the WASM module. During destruction, the following steps are executed sequentially: terminating WASM execution, releasing linear memory, and unloading OverlayFS. If any step in the destruction process fails (e.g., OverlayFS is occupied by an external process), the system enters isolation rollback mode: the instance is marked as a zombie, destruction is delayed and retried, and new instances are prevented from reusing the same resource paths to ensure no resource leaks or state escape occur.
[0074] IV. WASI Bridge Execution Flow:
[0075] When WASM calls a host function, the WASI bridge processes it in the following steps: First, it performs pointer conversion, converting the offset in WASM linear memory into a virtual address of the host process; then, it performs boundary checks to verify that the address does not exceed the allocated memory range; next, it performs permission checks, checking whether the call is allowed based on the permission bitmap in the capability mapping table; then, it executes the primitive call, invoking the native host function; finally, it writes the return value back to WASM memory.
[0076] The entire process is completed in user space, and permission checks and execution are performed atomically in the same operation, preventing security vulnerabilities caused by inconsistencies between the timing of checks and the timing of usage.
[0077] V. Capability Cache Expiration Mechanism:
[0078] The present invention proposes an event-driven capability cache invalidation mechanism to handle scenarios where the capabilities of the host system change dynamically.
[0079] like Figure 6 As shown, when a capability change event occurs in the host system (such as network interface disabling, security policy update, or hardware device removal), the daemon triggers a cache invalidation process. The daemon maintains a capability mapping table, recording the actual set of capabilities bound to each WASM instance. When a capability change event occurs, the daemon queries the capability mapping table, filters out the affected instance set, sends targeted invalidation notifications to these instances, and marks the corresponding cache entries as invalid.
[0080] Cache entries marked as invalid trigger a rebinding process the next time the corresponding host function is called. If binding fails (e.g., the capability has been revoked), the WASI bridge returns a specific error code to WASM, which the application can use for graceful degradation. This mechanism ensures the real-time nature of capability revocation and addresses the security vulnerability in traditional static binding schemes where the application can still call the capability even after it has been revoked.
[0081] VI. AOT Compilation Caching and Module Fingerprint Verification:
[0082] To further optimize the cold start performance of edge devices, this invention proposes an AOT (Ahead-Of-Time) compilation caching mechanism based on module fingerprints.
[0083] like Figure 7 As shown, when the WASM module is loaded for the first time, it undergoes AOT compilation at runtime, translating the bytecode into native machine code for the target platform. After compilation, the system calculates the module's unique fingerprint: taking the first 128 bits of the SHA-256 hash value of the module's binary content, concatenating it with the compiler version number (32 bits) and the target architecture identifier (32 bits), forming a 192-bit composite fingerprint. The compilation artifact is stored in the cache directory with the fingerprint as the filename.
[0084] When loading the same module subsequently, the system first calculates the fingerprint of the module to be loaded and checks if a matching entry exists in the cache directory. If a match is found and the fingerprint is completely identical, the pre-compiled native code is loaded directly, skipping the compilation stage; if a match is not found or the fingerprint does not match (e.g., due to module updates or compiler upgrades), recompilation is triggered and the cache is updated.
[0085] The fingerprint verification mechanism employs a two-level verification strategy: the first level is fast filename matching (O(1) hash lookup); the second level is integrity verification during loading (comparing the fingerprint stored in the cache file header with the currently calculated fingerprint bit by bit). The cache can only be used after both levels of verification pass, ensuring that tampered or expired compilation artifacts are not loaded.
[0086] The cache employs an LRU (Least Recently Used) eviction policy, and its capacity can be configured via startup parameters to adapt to edge devices with varying storage capacities. For embedded devices with extremely limited storage, caching can be disabled, and just-in-time compilation can be performed on every request.
[0087] This mechanism further reduces the startup time of repeatedly loading scenarios from milliseconds to microseconds, making it particularly suitable for high-frequency calls to the same module in edge computing scenarios.
[0088] Example 3:
[0089] This embodiment proposes a lightweight application distribution and isolated operation system for edge-cloud collaboration, including:
[0090] Cloud-based compilation and distribution module: It uses WASM bytecode as the only format for application distribution, compiles the application into a WASM module in the cloud, and then distributes it to the end devices;
[0091] End-side device module: At the file level, OverlayFS is used to merge the host read-only configuration data with the memory temporary file system Tmpfs and map it to a virtual file system within the WASM sandbox; at the symbol level, a dynamic WASI bridge is introduced to inject the host system's native capabilities into the WASM runtime in real time as host functions according to the import requirements of the WASM module, thus adapting to the heterogeneous hardware characteristics of the end-side device.
[0092] The end-side device module includes: an immutable host layer, a capability bridging layer, and a WASM sandbox layer;
[0093] The immutable host layer serves as the physical base, with its root file system mounted in read-only mode and merged with OverlayFS and Tmpfs.
[0094] The capability bridging layer runs in user space. Through the OverlayFS controller, WASI bridge, capability mapping table that records the set of host function requirements in the WASM module, and daemon process responsible for executing the application, it parses the requirements of the WASM module and dynamically builds restricted system call channels.
[0095] The WASM sandbox layer hosts the application, and all its external interactions are relayed through the capability bridging layer.
[0096] The end-side device module includes:
[0097] Application loading phase: When the terminal device receives the WASM module distributed by the cloud, it first calculates the composite fingerprint of the WASM module during loading through the daemon process, and queries the local AOT compilation cache. If the cache is hit and the fingerprint verification is successful, the local machine code in the AOT compilation cache is loaded directly to achieve microsecond-level startup; if the cache is not hit, just-in-time compilation or AOT compilation is performed and the compilation artifacts are cached to accelerate subsequent calls.
[0098] Runtime initialization phase: A zero-copy file system projection is constructed through OverlayFS, with the host read-only directory as the lower layer and Tmpfs as the upper layer, forming a virtual file system of the WASM sandbox; the WASM module imports segments to extract the capability requirement list, and initializes the capability mapping table in memory according to the capability requirement list;
[0099] Request processing phase: When a WASM module calls a host function for the first time, the WASI bridge intercepts the call, queries the capability mapping table, and performs pointer conversion, boundary checks, and permission verification before establishing a binding relationship with the host function and caching it; subsequent calls to the same interface directly hit the cache.
[0100] Dynamic response phase: When the host system undergoes capability changes, the daemon queries the capability mapping table and sends a targeted failure notification to the affected WASM instances. After receiving the failure notification, the WASM instances add an invalid tag to the corresponding entries. The cached entries marked as invalid trigger rebinding on the next call. If the capability has been revoked, an error code is returned.
[0101] Instance destruction phase: Based on the configured sandbox granularity, the system triggers the atomic destruction process at the appropriate time, terminating WASM execution, releasing linear memory, and unloading OverlayFS in reverse order according to the principle of reverse dependency. After destruction is completed, the host disk remains consistent before and after operation.
[0102] The capability mapping table adopts a two-level index structure: the first level is the WASM module name hash, and the second level is the function name hash; each table entry contains a function signature hash, a host function pointer, a permission bitmap, and a call counter; the call counter is used for anomaly detection.
[0103] When the WASM module is loaded for the first time, it is compiled at runtime using AOT to translate the bytecode into the native machine code of the target platform. After compilation, the unique fingerprint of the WASM module is calculated: the first few bits of the SHA-256 hash value of the binary content of the WASM module are taken, and the compiler version number and the target architecture identifier are concatenated to form a composite fingerprint. The compiled product (machine code) is stored in the cache directory with the fingerprint as the file name.
[0104] Building a zero-copy file system projection using OverlayFS includes: employing OverlayFS joint mounting technology, setting the host read-only directory as the lower layer and the memory temporary file system Tmpfs as the upper layer, merging the two and mapping them to a pre-open directory of the WASM sandbox; application read operations are directly passed through to the lower read-only layer to achieve zero copy; write operations trigger copy-on-write, with new data only stored in the upper memory layer; setting the volatile flag during mounting to ensure that upper layer data is not persisted; and automatically unloading OverlayFS and releasing Tmpfs when the WASM instance is destroyed.
[0105] WASM sandbox settings provide a configurable granularity for instantaneous sandbox mechanisms, including request-level sandboxes and session-level sandboxes. Request-level sandboxes are destroyed immediately after processing a single request, while session-level sandboxes are bound to the user session and destroyed uniformly when the session ends. Sandbox granularity is configured through startup parameters.
[0106] The execution flow of the WASI bridge includes: when the WASM module calls a host function, the WASI bridge first performs pointer conversion, converting the offset in WASM memory into the virtual address of the host process; then it performs boundary checks to verify that the address does not exceed the allocated memory range; next, it performs permission checks, checking whether the call is allowed based on the permission bitmap in the capability mapping table; then it executes primitive calls, calling the host native function; finally, it writes the return value back to WASM memory.
[0107] The lightweight application distribution and isolation operation system for end-to-cloud collaboration proposed in this embodiment can realize the lightweight application distribution and isolation operation method for end-to-cloud collaboration described in Embodiments 1 and 2, and has the same technical effect as Embodiments 1 and 2.
[0108] The above-described embodiments are merely preferred embodiments of the present invention and are only used to help understand the method and core ideas of this application. The scope of protection of the present invention is not limited to the above embodiments, and all technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.
Claims
1. A lightweight application distribution and isolated operation method for edge-cloud collaboration, characterized in that, include: S1. Use WASM bytecode as the only format for application distribution. Compile the application into a WASM module in the cloud and then distribute it to the end device. S2. At the file level, the end device uses OverlayFS to merge the host's read-only configuration data with the memory temporary file system Tmpfs and maps it to a virtual file system within the WASM sandbox. At the symbol level, a dynamic WASI bridge is introduced to inject the host system's native capabilities into the WASM runtime in real time as host functions (HostFunction) according to the import requirements of the WASM module, thus adapting to the heterogeneous hardware characteristics of the end device. The end-side device processing flow includes: S201, Application Loading Phase: When the terminal device receives the WASM module distributed from the cloud, it first calculates the composite fingerprint of the WASM module during loading via the daemon process, and queries the local AOT compilation cache. If the cache is hit and the fingerprint verification passes, the local machine code in the AOT compilation cache is loaded directly to achieve microsecond-level startup; if it is not hit, just-in-time compilation or AOT compilation followed by caching of compilation artifacts is performed to accelerate subsequent calls. S202, Runtime Initialization Phase: A zero-copy file system projection is constructed through OverlayFS, with the host read-only directory as the lower layer and Tmpfs as the upper layer, forming a virtual file system for the WASM sandbox; the WASM module imports segments to extract the capability requirement list, and initializes the capability mapping table in memory according to the capability requirement list; S203, Request Processing Phase: When the WASM module calls a host function for the first time, the WASI bridge intercepts the call, queries the capability mapping table, and performs pointer conversion, boundary checks, and permission verification before establishing a binding relationship with the host function and caching it; subsequent calls to the same interface directly hit the cache. S204, Dynamic Response Phase: When a capability change event occurs in the host system, the daemon process queries the instance-capability dependency relationship in the capability mapping table, filters out the set of affected instances, and sends a targeted failure notification to the affected WASM instances. After receiving the failure notification, the WASM instance adds an invalid tag to the corresponding entry; the cached entry marked as invalid will trigger rebinding on the next call, and if the capability has been revoked, an error code will be returned. S205, Instance Destruction Phase: Based on the configured sandbox granularity, the system triggers the atomic destruction process at the appropriate time, terminating WASM execution, releasing linear memory, and unloading OverlayFS in reverse order according to the principle of reverse dependency. After destruction is completed, the host disk remains consistent before and after operation.
2. The lightweight application distribution and isolated operation method for end-to-cloud collaboration according to claim 1, characterized in that, In step S2, the system architecture of the end-side device is set to three layers, including: an immutable host layer, a capability bridging layer, and a WASM sandbox layer. The immutable host layer serves as the physical base, with its root file system mounted in read-only mode and merged with OverlayFS and Tmpfs. The capability bridging layer runs in user space and parses WASM module requirements and dynamically constructs restricted system call channels through the OverlayFS controller, WASI bridge, capability mapping table that records the set of host function requirements in the WASM module, and the daemon process responsible for executing the application. The WASM sandbox layer carries the application, and all its external interactions are relayed through the capability bridging layer.
3. The lightweight application distribution and isolated operation method for end-to-cloud collaboration according to claim 1, characterized in that, The capability mapping table adopts a two-level index structure: the first level is the WASM module name hash, and the second level is the function name hash; each table entry contains a function signature hash, a host function pointer, a permission bitmap, and a call counter; the call counter is used for anomaly detection.
4. The lightweight application distribution and isolated operation method for end-to-cloud collaboration according to claim 1, characterized in that, When the WASM module is loaded for the first time in step S201, it is AOT compiled at runtime to translate the bytecode into the native machine code of the target platform. After compilation, the unique fingerprint of the WASM module is calculated: take the first few bits of the SHA-256 hash value of the binary content of the WASM module, concatenate the compiler version number and the target architecture identifier to form a composite fingerprint, and store the compilation product in the cache directory with the fingerprint as the file name.
5. The lightweight application distribution and isolated operation method for end-to-cloud collaboration according to claim 1, characterized in that, Step S202 involves constructing a zero-copy file system projection using OverlayFS, which includes: employing OverlayFS joint mounting technology, setting the host read-only directory as the lower layer and the memory temporary file system Tmpfs as the upper layer, merging the two and mapping them to the pre-open directory of the WASM sandbox; application read operations are directly passed through to the lower read-only layer to achieve zero copy; write operations trigger copy-on-write, and new data is only stored in the upper memory layer; a volatile flag is set during mounting to ensure that upper layer data is not persisted; when the WASM instance is destroyed, OverlayFS is automatically unloaded and Tmpfs is released.
6. The lightweight application distribution and isolated operation method for end-to-cloud collaboration according to claim 1, characterized in that, In step S202, the WASM sandbox settings include a configurable granular instantaneous sandbox mechanism, including request-level sandboxes and session-level sandboxes. Request-level sandboxes are destroyed immediately after processing a single request, while session-level sandboxes are bound to user sessions and destroyed uniformly when the session ends. The sandbox granularity is configured through startup parameters.
7. The lightweight application distribution and isolated operation method for end-to-cloud collaboration according to claim 1, characterized in that, The execution flow of the WASI bridge in step S203 includes: when the WASM module calls the host function, the WASI bridge first performs pointer conversion, converting the offset in WASM memory into the virtual address of the host process; then it performs boundary checks to verify that the address does not exceed the allocated memory range; next, it performs permission checks, checking whether the call is allowed based on the permission bitmap in the capability mapping table; then it executes primitive calls, calling the host native function; finally, it writes the return value back to WASM memory.
8. A lightweight application distribution and isolation operation system for edge-cloud collaboration, characterized in that, include: Cloud-based compilation and distribution module: It uses WASM bytecode as the only format for application distribution, compiles the application into a WASM module in the cloud, and then distributes it to the end devices; End-side device module: At the file level, OverlayFS is used to merge the host read-only configuration data with the memory temporary file system Tmpfs and map it to a virtual file system within the WASM sandbox; at the symbol level, a dynamic WASI bridge is introduced to inject the host system's native capabilities into the WASM runtime in real time as host functions HostFunctions according to the import requirements of the WASM module, adapting to the heterogeneous hardware characteristics of the end-side device. The end-side device module includes: Application loading phase: When the terminal device receives the WASM module distributed by the cloud, it first calculates the composite fingerprint of the WASM module during loading through the daemon process, and queries the local AOT compilation cache. If the cache is hit and the fingerprint verification is successful, the local machine code in the AOT compilation cache is loaded directly to achieve microsecond-level startup; if the cache is not hit, just-in-time compilation or AOT compilation is performed and the compilation artifacts are cached to accelerate subsequent calls. Runtime initialization phase: A zero-copy file system projection is constructed through OverlayFS, with the host read-only directory as the lower layer and Tmpfs as the upper layer, forming a virtual file system of the WASM sandbox; the WASM module imports segments to extract the capability requirement list, and initializes the capability mapping table in memory according to the capability requirement list; Request processing phase: When a WASM module calls a host function for the first time, the WASI bridge intercepts the call, queries the capability mapping table, and performs pointer conversion, boundary checks, and permission verification before establishing a binding relationship with the host function and caching it; subsequent calls to the same interface directly hit the cache. Dynamic response phase: When the host system undergoes capability changes, the daemon queries the capability mapping table and sends a targeted failure notification to the affected WASM instances. After receiving the failure notification, the WASM instances add an invalid tag to the corresponding entries. The cached entries marked as invalid trigger rebinding on the next call. If the capability has been revoked, an error code is returned. Instance destruction phase: Based on the configured sandbox granularity, the system triggers the atomic destruction process at the appropriate time, terminating WASM execution, releasing linear memory, and unloading OverlayFS in reverse order according to the principle of reverse dependency. After destruction is completed, the host disk remains consistent before and after operation.
9. The lightweight application distribution and isolated operation system for end-to-cloud collaboration according to claim 8, characterized in that, The edge device module includes: an immutable host layer, a capability bridging layer, and a WASM sandbox layer; The immutable host layer serves as the physical base, with its root file system mounted in read-only mode and merged with OverlayFS and Tmpfs. The capability bridging layer runs in user space. Through the OverlayFS controller, WASI bridge, capability mapping table that records the set of host function requirements in the WASM module, and daemon process responsible for executing the application, it parses the requirements of the WASM module and dynamically builds restricted system call channels. The WASM sandbox layer hosts the application, and all its external interactions are relayed through the capability bridging layer.