Patch updating method and device, electronic equipment, storage medium and program product

Abstract

The present disclosure relates to the technical field of patch updating, and provides a patch updating method and device, electronic equipment, a storage medium and a program product. The method comprises: receiving a target patch for updating a first patch module in a host program; instantiating the target patch in a Wasm sandbox environment to obtain a second patch module; allocating memory space for the second patch module in the Wasm sandbox environment; migrating state data of the first patch module to the second patch module; processing, in parallel, service requests for the host program by using the first patch module and the second patch module; and in response to completion of processing of all service requests received before the migration starts, uninstalling the first patch module and taking the second patch module as an updated first patch module. The present disclosure solves the problems of service interruption and poor update security during patch updating, and can complete patch switching in a service interruption-free and security-isolated manner, thereby realizing zero-interruption patch updating.

Description

Technical Field

[0001] This disclosure relates to the field of patch update technology, and in particular to a patch update method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] In program runtime environments such as server operating systems and containerized deployment environments, software upgrades and defect fixes are core requirements for daily operations and maintenance.

[0003] With the widespread adoption of cloud computing and microservice architectures, the requirements for service continuity are becoming increasingly stringent. However, traditional patch upgrade methods involve operations such as binary file replacement, dynamic link library updates, or container image reconstruction. These operations often require restarting the service process. Furthermore, during the update process, testing or running the new patch may grant unauthorized access to the host program, making it difficult to perform patch upgrades with zero downtime and secure isolation. This can lead to problems such as service interruptions, connection drops, cache invalidation, and unauthorized modification of the host's original data. Summary of the Invention

[0004] To address the issues of service interruption caused by restarting program processes during patch updates and the difficulty in ensuring that the original host program is not modified during the update process, this disclosure provides a patch update method, apparatus, electronic device, storage medium, and program product to at least solve or alleviate the aforementioned problems. The technical solution of this disclosure is as follows: According to a first aspect of this disclosure, a patch update method is provided, the patch update method comprising: receiving a target patch for updating a first patch module in a host program, wherein the target patch includes a Wasm module; instantiating the target patch in a Wasm sandbox environment to obtain a second patch module, wherein the Wasm sandbox environment is the same as the production environment in which the host program is located; allocating memory space for the second patch module in the Wasm sandbox environment; migrating the current state data of the first patch module to the second patch module if state data exists in the first patch module; and using the first patch module and the second patch module to process business requests for the host program in parallel, wherein the first patch module is used to process requests before the migration begins. Upon receiving a service request, the second patch module is used to process service requests received after the migration begins; in response to the completion of processing of all service requests received before the migration begins, the first patch module is unloaded, and the second patch module is used as the updated first patch module. The allocation of memory space for the second patch module in the Wasm sandbox environment includes: allocating a target linear memory space for the second patch module in the Wasm sandbox environment via the Wasm runtime, wherein the target linear memory space is physically independent of the host program's process address space; configuring a permission mask for the target linear memory space, wherein the permission mask is used to physically restrict the instruction flow of the second patch module to a preset page table range within the linear memory space.

[0005] Optionally, migrating the current status data of the first patch module to the second patch module includes: comparing the priority between the target patch and the currently active patch corresponding to the first patch module; if the priority of the target patch is higher than the priority of the currently active patch, migrating the current status data of the first patch module to the second patch module; if the priority of the target patch is lower than or equal to the priority of the currently active patch, using the second patch module as a backup patch module for the first patch module and exiting patch updates.

[0006] Optionally, the patch update method further includes: if the priority of the target patch is higher than the priority of the currently active patch, replacing the priority information of the currently active patch stored in the head of a preset patch priority linked list with the priority information of the target patch; if the priority of the target patch is lower than or equal to the priority of the currently active patch, creating a successor node linked to the head of the linked list, and storing the priority information of the target patch in the successor node.

[0007] Optionally, after performing the steps of uninstalling the first patch module and using the second patch module as the updated first patch module, the patch update method further includes: determining a first runtime error rate of the uninstalled first patch module, a first resource consumption of the uninstalled first patch module, a second runtime error rate of the updated first patch module, and a second resource consumption of executing the updated first patch module; determining a first score of the uninstalled first patch module based on the priority of the uninstalled first patch module, the first runtime error rate, and the first resource consumption; determining a second score of the updated first patch module based on the priority of the updated first patch module, the second runtime error rate, and the second resource consumption; and updating the updated first patch module with the uninstalled first patch module if the first score is lower than the second score.

[0008] Optionally, after performing the step of instantiating the target patch in the Wasm sandbox environment to obtain the second patch module, the patch update method further includes: performing a health check and resource consumption verification on the second patch module in the Wasm sandbox environment; in response to the second patch module passing the health check and the resource consumption verification, performing the step of migrating the current state data of the first patch module to the second patch module when state data exists in the first patch module, wherein the health check includes: checking the runtime error rate of the second patch module, wherein the resource consumption verification includes: verifying the resource consumption required to execute the second patch module through patch injection; in response to the deviation of the resource consumption from a preset baseline exceeding a preset threshold, determining that the second patch module has failed the resource consumption verification; in response to the deviation not exceeding the preset threshold, determining that the second patch module has passed the resource consumption verification.

[0009] Optionally, migrating the current state data of the first patch module to the second patch module includes: freezing the first patch module; exporting and transmitting the current state data of the first patch module in blocks to the second patch module; reconstructing the block data transmitted to the second patch module as the internal state of the second patch module in a temporary storage area; and switching the internal state pointer of the second patch module from the temporary storage area to the formal storage area in response to confirming that the block data has been correctly received.

[0010] Optionally, migrating the current state data of the first patch module to the second patch module includes: determining the version of the target patch and the version of the currently active patch corresponding to the first patch module; migrating the original data of the current state data of the first patch module to the second patch module in response to the version of the target patch being the same as the version of the currently active patch; converting the current state data of the first patch module to obtain converted data in response to the version of the target patch being different from the version of the currently active patch; and migrating the converted data to the second patch module.

[0011] Optionally, the step of converting the current state data of the first patch module to obtain the converted data includes: determining a conversion function from the version of the currently active patch to the version of the target patch according to a preset version mapping table, wherein the conversion function includes a built-in function of the Wasm module and / or a conversion script pre-embedded in the host program; and converting the current state data of the first patch module based on the conversion function to obtain the converted data.

[0012] Optionally, the parallel processing of service requests for the host program using the first patch module and the second patch module includes: adding preset tag information to service requests received after the migration begins; during the process of the host program processing the service request sequence, selecting a patch module from the first patch module and the second patch module to process the current service request based on whether the current service request carries the preset tag information, wherein, in response to determining that the current service request carries the preset tag information, the second patch module is used to process the current service request, and in response to determining that the current service request does not carry the preset tag information, the first patch module is used to process the current service request.

[0013] According to a second aspect of this disclosure, a patch update apparatus is provided, comprising: a receiving unit configured to receive a target patch for updating a first patch module in a host program, wherein the target patch includes a Wasm module; an instantiation unit configured to instantiate the target patch in a Wasm sandbox environment to obtain a second patch module, wherein the Wasm sandbox environment is the same as the production environment in which the host program is located; an allocation unit configured to allocate memory space for the second patch module in the Wasm sandbox environment; a migration unit configured to migrate the current state data of the first patch module to the second patch module if state data exists in the first patch module; a processing unit configured to process business requests for the host program in parallel using the first patch module and the second patch module, wherein the first patch module is used to process business requests received before the migration begins, and the second patch module is used to process business requests received after the migration begins; and an update unit configured to, in response to the completion of processing of all business requests received before the migration begins, unload the first patch module and use the second patch module as the updated first patch module.

[0014] According to a third aspect of this disclosure, a computing device is provided, the computing device comprising: a processor; and a memory for storing computer-executable instructions, wherein the computer-executable instructions, when executed by the processor, cause the processor to perform a patch update method according to this disclosure.

[0015] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of a computing device, enables the computing device to perform the patch update method according to this disclosure.

[0016] According to a fifth aspect of this disclosure, a computer program product is provided, including computer-executable instructions that, when executed by at least one processor, implement the patch update method according to this disclosure.

[0017] The technical solution provided in this disclosure brings at least the following beneficial effects: By adopting the patch update scheme disclosed herein, when updating the first patch module in the host program, the target patch can be instantiated in the Wasm sandbox environment to obtain the second patch module without stopping the first patch module. Memory space is allocated for the second patch module in the sandbox environment, and the state data of the first patch module is migrated to the second patch module. Then, the first patch module and the second patch module can be used to process business requests for the host program in parallel until all existing requests for the first patch module are processed. The second patch module then officially replaces the first patch module. In this way, the switch of patch modules can be completed without service interruption and without the user's awareness, achieving zero-interruption patch updates. Furthermore, the logic of the second patch module is restricted to the linear memory boundary in the Wasm sandbox and cannot escape into the address space of the host program, ensuring the normal operation of the host program and preventing the host program's data from being tampered with without authorization.

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

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0020] Figure 1 This is a schematic flowchart of a patch update method according to an exemplary embodiment of the present disclosure.

[0021] Figure 2 This is a schematic flowchart illustrating the instantiation of a target patch according to an exemplary embodiment of the present disclosure.

[0022] Figure 3 This is a schematic flowchart illustrating the migration of state data from a first patch module to a second patch module according to an exemplary embodiment of the present disclosure.

[0023] Figure 4 This is an illustrative flowchart illustrating the migration of state data based on the version of a patch, according to an exemplary embodiment of this disclosure.

[0024] Figure 5 This is an illustrative flowchart illustrating how a first patch module and a second patch module process service requests in parallel, according to an exemplary embodiment of this disclosure.

[0025] Figure 6 This is a schematic diagram of an example architecture for implementing a patch update method according to exemplary embodiments of the present disclosure.

[0026] Figure 7This is a schematic flowchart illustrating an application example of a patch update method according to an exemplary embodiment of the present disclosure.

[0027] Figure 8 This is a schematic block diagram of a patch update apparatus according to exemplary embodiments of the present disclosure.

[0028] Figure 9 This is a block diagram of a computing device according to exemplary embodiments of the present disclosure. Detailed Implementation

[0029] In order to enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0030] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0031] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0032] To facilitate understanding of the exemplary embodiments of this disclosure, the relevant concepts involved herein are first explained: Wasm: short for WebAssembly, a low-level bytecode patching format designed for stacked virtual machines, which can execute code efficiently and securely in a sandbox.

[0033] WASI (WebAssembly System Interface): The WebAssembly system interface is a standardized system interface specification developed by the Bytecode Consortium. It provides secure system-level API access capabilities (such as file systems, networks, clocks, etc.) for Wasm modules, enabling Wasm modules to run across platforms.

[0034] Application Binary Interface (ABI): Defines the binary-level interaction specifications between modules.

[0035] The Open Container Initiative (OCI) defines container image formats and runtime standards.

[0036] Wasm Interface Types (WIT): Used to describe the interfaces for module import and export functions.

[0037] As mentioned earlier, during the program update process, there is a problem that the program process needs to be restarted, which may cause service interruption.

[0038] For example, consider hot-replacement of dynamic link libraries (DLLs). In C / C++ programs, functionality can be extended using DLLs. When an update is needed, the shared library file on disk is replaced, and then the program is triggered to reload the library via a signal. However, hot-replacement of DLLs requires restarting the process, or at least the worker process, resulting in a brief service interruption (e.g., connection loss), which has a significant impact in high-concurrency scenarios.

[0039] Furthermore, this approach relies on signal mechanisms, making it difficult to safely unload old libraries in multi-threaded programs, posing a risk of race conditions. Additionally, since the library code has access to the entire process space, malicious code or vulnerabilities could cause the entire process to crash or be compromised, compromising security. Moreover, the complex version dependencies of shared libraries can easily lead to nested dependency conflicts.

[0040] For example, OpenResty or Redis support Lua script extensions. When a script file is updated, it is reloaded via the built-in loadfile mechanism, and new requests use the new script logic. For instance, Redis's EVAL command supports script caching; however, script updates require restarting Redis or manually calling SCRIPT FLUSH and reloading.

[0041] Furthermore, in this approach, Lua's interpreted execution efficiency is significantly lower than compiled code, resulting in insufficient performance in CPU-intensive scenarios. Additionally, since the script shares memory with the host, malicious scripts could corrupt host process data. Moreover, if the script contains syntax errors or runtime exceptions during hot reloading, it may cause service unavailability. Furthermore, dynamically typed languages ​​lack compile-time checks, making it difficult to detect runtime errors in advance.

[0042] For example, eBPF (Extended Berkeley Packet Filter) technology allows for dynamic loading of programs in kernel mode or restricted user mode, and is commonly used in scenarios such as network filtering and performance monitoring. However, the eBPF programming model is limited, making it difficult to implement complex business logic, and it is mainly applicable to the Linux kernel mode, limiting its versatility and failing to support complex data structures and algorithms. Furthermore, since the technology primarily supports the Linux kernel, its cross-platform capabilities are poor, and kernel-mode debugging is complex and costly in locating problems.

[0043] Overall, the relevant patch update technologies suffer from problems such as service interruption, insufficient security isolation, performance loss, and state loss.

[0044] In view of this, exemplary embodiments of the present disclosure provide a patch update method, patch update apparatus, computing device, computer-readable storage medium, and computer program product that can solve or at least alleviate the above-mentioned problems.

[0045] In a first aspect of an exemplary embodiment of this disclosure, a patch update method is provided. This method can be applied to scenarios where a patch module in a host program is being updated. During the execution of the host program, in response to receiving a patch update instruction for a first patch module, a target patch can be received, and the first patch module can be updated by executing the patch update method according to an embodiment of this disclosure.

[0046] The aforementioned host program can be loaded onto a computing device, which may be, but is not limited to, a desktop computer, laptop computer, tablet computer, personal digital assistant, smartphone, or other device capable of supporting program execution. However, the implementation scenario of the above method is merely an example scenario. The method according to the exemplary embodiments of this disclosure can also be applied to other application scenarios. For example, a user may request an update patch from a server via a network on a user terminal (e.g., a mobile phone, desktop computer, tablet computer, etc.), and the server may implement the patch update by executing the method according to the exemplary embodiments of this disclosure. Here, the server may be a standalone server, a server cluster, a cloud computing platform, or a virtualization center.

[0047] The following description, with reference to the accompanying drawings, illustrates an example of a patch update method according to an embodiment of this disclosure, which may be executed, for example, by a host program. Figure 1 As shown, the patch update method may include the following steps: In step 110, a target patch for updating the first patch module in the host program can be received.

[0048] In embodiments of this disclosure, the host program can be any software program, such as the CoreDNS process; the patch module can refer to a patch set module that includes at least one patch, and updating the patch module can refer to updating the patches in the patch set module, for example, it can include: replacing the corresponding patch in the patch set module with the target patch; and / or, adding the target patch to the patch set module. In step 110, the first patch module can be the patch set module before the update or the patch set module to be updated.

[0049] The target patch may include a Wasm module. Wasm (WebAssembly) is a low-level bytecode patching format designed for stacked virtual machines, which can execute code efficiently and securely in a sandbox. During the execution of the host program, for example, the host program may receive or retrieve the target patch in response to a patch update instruction for the first patch module received from a user, server, or other external system, in order to perform subsequent updates.

[0050] As an example, the target patch can be pre-generated. For instance, the target patch can be generated by: obtaining the source code of the business logic; compiling the source code to generate Wasm bytecode; and injecting the patch version number and patch priority into the Wasm bytecode to obtain the target patch.

[0051] In the above process, the source code for the business logic can be provided by the user, and it can be, for example, but not limited to, Wasm target languages ​​such as Rust, Go, C / C++, and AssemblyScript. For example, commands such as "uos-wasmplugin build" can be used to call language-specific toolchains (such as the "cargo build --target wasm32-wasi" toolchain or the "tinygobuild-target=wasi" toolchain) to compile the source code and generate the aforementioned Wasm bytecode.

[0052] In the embodiments of this disclosure, to support subsequent patch update operations, metadata injection and patch policy priority injection can be performed in the generated Wasm bytecode. For example, in metadata injection, the patch version number can be automatically injected. Here, the version number can be a semantic version, such as v1, v2, v3, etc. In patch policy priority injection, the priority of the target patch to be generated can be added to the Wasm bytecode. The priority of the target patch can be given by the user. For example, the priority of the patch can be represented by a number in the range of 0 to 99. The larger the number, the lower the priority. In patch updates, patches with the same priority can be mounted through a priority list and applied based on the first-in, first-out policy (which will be described in detail below). In addition, the priority of the target patch can be defaulted. For example, if the user has not configured the priority, it can be set to the lowest priority, such as a default priority of 99.

[0053] In addition, metadata injection may include, but is not limited to, build timestamps, source code hashes, and Application Binary Interface (ABI) compatibility descriptions. The ABI can define binary-level interaction specifications between modules, and the ABI compatibility description can be defined through the WIT interface. Here, the WIT (WebAssemblyInterface Types) interface refers to the interface of the Wasm interface type, which is used to describe the import and export functions of a module.

[0054] In addition, as an example, a digital signature can be added to the Wasm bytecode. For instance, the module can be digitally signed using an algorithm such as Ed25519, generating a digital signature block, which is then appended to the end of the Wasm file to prevent the target patch from being tampered with.

[0055] As an example, the above patch building process can be executed using the following command to obtain the target patch: "uos-wasmplugin build --input log_processor.rs \ --output log_processor.whp --wit dns_log.wit \ --version 1.2.3 --priority 99 \ --sign-key / path / to / private.key".

[0056] By performing the above patch creation process, a standard patch package (e.g., a .whp file) can be output as the target patch. This target patch may include, but is not limited to, the following: Wasm module, WIT interface definition, metadata (e.g., JSON format), digital signature block, etc.

[0057] The above describes the process of receiving the target patch. (Refer to the previous section.) Figure 1 In step 120, the target patch can be instantiated in the Wasm sandbox environment to obtain the second patch module.

[0058] Here, the Wasm sandbox environment can be the same as the production environment in which the host program resides.

[0059] In embodiments of this disclosure, a second patch module can be obtained by instantiating the target patch in a Wasm sandbox environment. Here, the second patch module can be a patch set module containing the target patch, which can be obtained, for example, by using the target patch to update the patch in the current patch set module (i.e., the first patch module described above).

[0060] As an example, before a patch officially takes effect, the system can perform Ahead-of-Time (AOT) compilation in a background thread to instantiate the target patch. This instantiation allows the target patch to complete initialization tests (e.g., stream verification via the `init()` method) in isolated memory without being directly connected to the stream. By monitoring its memory page allocation frequency, "memory-overload" patches can be identified and intercepted in advance. Before the patch officially takes effect, stream verification can be performed via `init()` in isolated memory using AOT-compiled machine code.

[0061] The above methods can be used to test the functionality of the target patch and to audit its resource usage through instruction monitoring, ensuring that it does not cause memory overflow or CPU starvation.

[0062] Furthermore, as an example, in embodiments of this disclosure, local verification (Secure Distribution) can be performed on the target patch and / or the second patch module. Subsequent steps can proceed after the second patch module passes local verification. Here, local verification can refer to verification of the target patch and / or the second patch module (or patch set module) instantiated based on the target patch. Alternatively, during local verification, the host program may not be involved; instead, verification may be performed on the target patch and / or the second patch module itself.

[0063] Specifically, the patch update method may further include: performing a health check and resource consumption verification on the second patch module in a Wasm sandbox environment; and executing subsequent steps 130 in response to the second patch module passing the health check and resource consumption verification.

[0064] Health checks may include checking the runtime error rate of the second patch module.

[0065] Resource consumption verification may include: verifying the resource consumption required to execute the second patch module through patch injection; determining that the second patch module fails the resource consumption verification if the deviation of the resource consumption from the preset baseline exceeds a preset threshold; and determining that the second patch module passes the resource consumption verification if the deviation does not exceed the preset threshold.

[0066] Specifically, in resource exhaustion verification, the average number of patches executed by the second patch module (or patch set module) can be counted through patch injection (Instruction Instrumentation). If its resource consumption characteristics deviate from the preset baseline by more than a threshold, the verification is deemed to have failed. This can effectively prevent malicious patches or logical infinite loops from entering the production environment. The aforementioned preset baseline can be set according to actual needs, for example, it can be a historical baseline obtained by statistically analyzing historical data.

[0067] As an example, in addition to the health checks and resource consumption verification mentioned above, local verification of the second patch module may also include the following operations: patch package parsing and signature verification; creation of a local sandbox environment; static interface compatibility checks; functional correctness auditing; security auditing; performance benchmarking; interface connectivity testing; and audit report output.

[0068] Specifically, in local verification, the Wasm patch package built using tools such as uos-wasmplugin, as described above, can be used with the verify command of uos-wasmplugin to perform a comprehensive pre-verification audit of the built patch package (e.g., .whp file) in a local sandbox environment. This ensures that the patch does not have functional defects, security vulnerabilities, or interface incompatibility issues before being loaded into the production environment, and ultimately generates security audit results and risk assessment reports.

[0069] For example, patch package parsing and signature verification may include: parsing the target patch (e.g., a .whp file); extracting the Wasm module, WIT interface definition, metadata, and digital signature block from the target patch; and verifying the signature of the digital signature block using a public key to ensure that the patch package origin is trustworthy and has not been tampered with. Here, if the verification result indicates that the signature of the digital signature block is invalid, the verification failure can be returned directly, and the patch update process can be terminated.

[0070] For example, creating a local sandbox environment can include starting a standalone Wasm sandbox instance locally (e.g., on the host executing the verification commands mentioned above), allocating isolated linear memory space based on the Wazero runtime. Here, the Wasm sandbox configuration can be consistent with the production environment (e.g., memory limits, CPU time slices, file descriptor limits) to ensure the portability of verification results.

[0071] For example, static interface compatibility checks can include: parsing the WIT interface definition in the target patch; and performing a static comparison with the host function signatures exposed by the host program's service (or the target service) to check whether the function name, parameter types, and return value types match perfectly. This ensures that the target patch will not crash due to minor parameter type adjustments (such as changing from i32 to i64) when calling host functions (such as logging, network input / output, I / O). This is a compile-stage security guarantee that cannot be achieved in traditional binary patches.

[0072] In addition, static interface compatibility checks may also include: verifying whether the second patch module exports preset interface functions, which may include at least: initialization functions (e.g., init()) and health check functions (e.g., health_check()). Furthermore, to enable subsequent state transitions, static interface compatibility checks may also include: checking for the existence of export state functions (e.g., export_state()), import state functions (e.g., import_state()), and verification state functions (e.g., verify_state()), and checking whether the signatures of each state function are correct.

[0073] For example, functional correctness auditing may include: instantiating a second patch module based on the target patch in the Wasm sandbox and calling `init()` to complete initialization. Here, mock test cases can be automatically generated according to the WIT definition, sequentially calling the business functions of the second patch module (e.g., `process_query`), passing in mock inputs that conform to the interface definition, and checking whether the output meets expectations.

[0074] In addition, for functional correctness auditing, users can provide custom test scripts (e.g., via the "--test-script" parameter) to run in the Wasm sandbox to verify the correctness of complex business logic.

[0075] For example, security audits may include the resource exhaustion tests described above, as well as memory boundary tests and isolation tests.

[0076] Specifically, memory boundary testing can refer to passing excessively long inputs or illegal pointers to the second patch module to detect out-of-bounds reads / writes or crashes. Isolation testing can refer to attempting to access host memory or make illegal system calls (such as directly opening a file) within the second patch module to verify whether the Wasm sandbox's isolation mechanism is effective.

[0077] For example, performance benchmarking could include running standard performance test cases in a Wasm sandbox and recording the average latency, throughput, and network latency of the second patch module. As an example, the performance test results of the patch module could be compared to the performance baseline of the current production version, and a warning or direct verification failure could be issued if the performance degradation exceeds a threshold (e.g., 20%).

[0078] For example, interface connectivity testing can include simulating host calls and verifying bidirectional calls.

[0079] Simulated host calls can include testing whether the second patch module's calls to host program functions (such as logging and configuration reading) function correctly, through the host program's function proxy. Bidirectional call verification can include ensuring that after the second patch module calls a function in the host program, the host program's function returns data, and the second patch module processes it correctly.

[0080] During the audit report output process, a structured report in formats such as JSON or visualizations can be generated after the security audit is completed. The structured report may include, but is not limited to, the following key items: signature verification result (pass or fail); interface compatibility check result (pass or fail, listing mismatches); functional test result (pass or fail, listing failed test cases); security test result (pass, warning, or failure, describing specific risks); performance test result (latency, throughput, and baseline comparison results). If all the above key items pass, the local verification is considered successful, and an exit code "0" is returned; otherwise, a non-zero exit code is returned, and the reason for the failure is indicated in the structured report.

[0081] The above describes an example process for local verification of the target patch and / or the second patch module. It should be noted that in the embodiments of this disclosure, any at least part of the verification process in the above local verification can also be omitted.

[0082] In step 130, memory space can be allocated for the second patch module in the Wasm sandbox environment.

[0083] In this step, memory space can be allocated for the second patch module in the Wasm sandbox environment, and the memory space allocated to the second patch module can be physically isolated from the process address space of the host program, thereby preventing the operation of the second patch module from affecting the process of the host program.

[0084] Here, the Wasm sandbox environment provides an independent patch runtime space and can simulate the production environment after a patch module is enabled. Generating the second patch module in isolation from the first patch module within the Wasm sandbox environment allows multiple patch sets to coexist in their respective independent sandboxes. It also allows the first patch module to be deactivated only after the second patch module is confirmed to be usable, enabling online upgrades of patches before updating the patch module. Compared to the overwrite mechanism in related technologies that directly replaces old code with new patches, this avoids the need to re-execute complex loading processes when the new patch becomes invalid, ensuring the reliability of patch updates.

[0085] As an example, such as Figure 2 As shown, step 130 above may include the following steps: In step 210, the target linear memory space can be allocated for the second patch module in the Wasm sandbox environment via the Wasm runtime.

[0086] Here, the target linear memory space can be physically independent of the host program's process address space.

[0087] In traditional patch updates, patches such as ".so" files or JAR packages share the process address space with the host program. Thus, if the patch crashes, it can cause the entire host program's service to crash.

[0088] In embodiments of this disclosure, for example, the Wazero runtime in Wasm can allocate an independent linear memory space for each patch module. This linear memory space is physically a contiguous block of memory (e.g., ArrayBuffer). The patch set module, or patch module, can only access its internal address and cannot access the host process's sensitive memory through any offset means.

[0089] In this way, by completely enclosing the patching logic of the patch module in an independent physical page, any illegal pointer offset within the patch module is restricted to the boundary of Wasm linear memory and cannot escape into the host process address space. Unlike the traditional scheme where the patch module shares the stack with the host, the embodiments of this disclosure can achieve physical-level isolation between the second patch module and the host program without sharing the stack, thereby improving the reliability of patch updates and the security of the host program.

[0090] In step 220, a permission mask can be configured for the target linear memory space.

[0091] Here, the permission mask can be used to physically restrict the instruction flow of the second patch module to the range of a preset page table in the linear memory space.

[0092] For example, the host program can utilize the operating system's Memory Management Unit (MMU) to configure a specific permission mask for the target linear memory space within the Wasm sandbox environment. This permission mask physically restricts the instruction flow of the target patch's code to a protected page table range. Thus, even if the patch logic is tampered with by a hacker, its destructive behavior is locked within the Wasm sandbox, achieving physical-level fault domain isolation. Here, the host program can use the MMU to set strict read / write / execute (RWX) permissions on the sandbox memory, making the target patch's code segment read-only and writable in memory, preventing the target patch from being tampered with again by malicious code during runtime.

[0093] Furthermore, as an example, after allocating memory space for the second patch module, an online upgrade can be performed on it. Here, online upgrade can refer to interfacing with or embedding the second patch module into the host program to verify its operation within the host program. For example, host program functions (such as logging, configuration reading, and network access) can be imported based on the second patch module to establish a bidirectional call channel between the second patch module and the host program.

[0094] In addition, the above-mentioned online upgrade may also include, for example, a patch check process for the second patch module. If the patch check passes, the subsequent step 140 is executed; if the patch check fails, the current patch update process can be exited.

[0095] For example, patch checks may include at least one of the following: service health checks, version compatibility verification, resource adequacy checks, and dependency conflict detection.

[0096] Specifically, service health checks can be used to confirm whether a target service is in a healthy state and currently has no alarms or degrades.

[0097] Version compatibility verification may include: parsing the WIT interface definition in the target patch; performing an ABI compatibility comparison between the parsed WIT interface definition and the host function interface currently exposed by the host program; determining that the target patch passes version compatibility verification if the function signature, parameter type, and return type match completely; and determining that the target patch fails version compatibility verification if at least one of the function signature, parameter type, and return type does not match.

[0098] Resource adequacy checks may include checking whether the operating system's current memory reserves meet the requirements for instantiating the target patch. Here, memory reserves may include Wasm linear memory reserves and / or AOT compilation cache reserves. Additionally, resource adequacy checks may also include checking whether resources such as file handles and thread pools are sufficient.

[0099] When a patch module depends on an external shared library (e.g., via the WASI interface), dependency conflict detection can be performed to verify the version compatibility of the target patch and prevent symbol conflicts.

[0100] Furthermore, as an example, after performing step 130 above and before performing step 140 as described below, the patch update method may also include at least one of the following operations: warming up the second patch module; performing digital signature verification on the second patch module; performing WIT interface compliance checks on the second patch module; performing health check calls on the second patch module; setting resource limits on the second patch module; and marking traffic on the second patch module.

[0101] For example, warming up the second patch module may include: triggering lifecycle hooks such as init() of the second patch module to complete operations such as initializing internal data structures, warming up the connection pool, and loading the cache; and performing restricted host function call tests on the second patch module when it does not receive production traffic.

[0102] For example, digital signature verification of the second patch module may include: using a preset verification algorithm such as Ed25519 to verify the signature of the second patch module to ensure that the patch module is of credible origin and has not been tampered with.

[0103] For example, performing a WIT interface compliance check on the second patch module may include: verifying through the Wasm runtime whether the exported functions of the second patch module conform to the WIT interface definition to prevent call failures caused by interface mismatch.

[0104] For example, a health check call to the second patch module may include: calling the health check interface exposed by the second patch module (such as the health_check() function) to verify the initialization state, dependent service connectivity, and internal state consistency of the second patch module.

[0105] For example, setting resource limits for the second patch module may include configuring resource quotas for the second patch module (such as, but not limited to, CPU time slices, memory limits, and file descriptor limits) through the WASI interface to prevent the abnormal module from exhausting system resources.

[0106] For example, traffic tagging of the second patch module may include registering the version identifier of the second patch module in the host program (such as the request router of the CoreDNS process) for use in subsequent traffic switching logic (described below).

[0107] During the above operations, you can execute commands such as uos-wasmplugin load.<module_name><patch.whp> These operations enable the tool to interact with the target service's management application programming interface (API) to perform zero-downtime upgrades of patches.

[0108] Return to reference Figure 1 In step 140, if the first patch module has status data, the current status data of the first patch module can be migrated to the second patch module.

[0109] In this step, if the first patch module has state data, state migration can be used to migrate the current state data of the first patch module to the second patch module, ensuring that the internal state of the second patch module is consistent with that of the first patch module. Alternatively, if the first patch module does not have state data, step 140 can be skipped, and subsequent step 150 can be executed. Here, state data can refer to variable information describing the dynamic state of the host program at a specific moment (e.g., running, shutting down, faulty, location, stage, etc.), and the current state data of the first patch module can refer to the state data of the host program contained within the first patch module.

[0110] As an example, such as Figure 3 As shown, step 140 may include the following steps: In step 310, the first patch module can be frozen.

[0111] Specifically, before the formal state migration is performed, the first patch module can be frozen to "read-only mode". In this mode, the first patch module enters an atomic freeze state, read requests continue, and write requests are cached to the operation log (such as the Write-Ahead Log), ensuring zero data loss during the migration.

[0112] While frozen, the first patch module continues to process existing read requests but rejects any new requests that would modify the state (such as writing to the cache or updating the session). Modification requests are temporarily cached or a "retry" error code is returned, awaiting processing by the second patch module after the migration is complete.

[0113] Furthermore, as an example, in step 310, the freezing of the first patch module can be achieved through atomic state machine switching to ensure that there are no partial write operations at the moment of freezing.

[0114] After the freeze ends, the timestamp and size of the current state of the first patch can be received and recorded from the first patch module for use in subsequent block transmission in step 320.

[0115] Furthermore, as an example, before executing the above-mentioned freezing of the first patch module, step 310 may also include: checking whether all state interfaces of the first patch module and the second patch module are complete; if all state interfaces are complete, executing the above-mentioned freezing of the first patch module; if at least one state interface of the first patch module and / or the second patch module is missing, exiting the current patch update process.

[0116] Specifically, it can be checked whether both the first patch module and the second patch module have implemented the export state function (e.g., export_state()), import state function (e.g., import_state()), and verification state function (e.g., verify_state()). If any state function is missing, subsequent state transitions can be refused and the first patch module can remain active.

[0117] Furthermore, as an example, before executing the aforementioned freeze of the first patch module, step 310 may also include: notifying the first patch module that a hook function (e.g., prepare_freeze()) is about to be performed, thus informing the first patch module that a state export is imminent. The first patch module should complete any pending write operations at this stage, bringing its internal data structures to a consistent state.

[0118] Furthermore, to handle modification requests that the first patch module may receive during the migration process (although the freeze mode will reject write requests, some business logic cannot completely avoid this), a write-ahead log mode can be supported. For example, while the first patch module is frozen, it serializes all requests to modify the state into a circular buffer. After the state migration is successful, the second patch module can replay these logs to ensure consistency before and after the state migration.

[0119] Return to reference Figure 3 In step 320, the current status data of the first patch module can be exported in blocks and transmitted to the second patch module.

[0120] Considering that for large states (such as cache or session data exceeding 1MB), one-time serialization may cause excessive memory spikes or block the event loop, this step can be achieved by using chunked transfer such as export_state_chunk, and chunked verification such as full hashing at the end, to prevent excessive memory spikes from causing host crashes, thus enabling chunked export and streaming.

[0121] As an example, the maximum exported chunk size of the first patch module can be queried (e.g., by querying the parameter `max_chunk_size`) to determine the chunk size. Here, the chunk size can be set to 64KB by default. Furthermore, the second patch module can declare its supported maximum import chunk size. In this step, the smaller of the maximum exported chunk size and the maximum imported chunk size can be used as the actual chunk size. Based on this actual chunk size, the current state data of the first patch module is divided, and chunked export is performed.

[0122] For example, an extension interface can be implemented in the first patch module for chunked export. Here, an example of the extension interface is: "export_state_chunk(ctx: u32, chunk_index: u32, out_buf:&mut [u8])->(len: u32, has_more: bool)", which exports one chunk of data each time it is called. The parameter chunk_index represents the chunk index (or chunk number), which can start from 0 and increment with each call.

[0123] As an example, after each block is transmitted, the actual block length written can be received from the second patch module, and it can be checked whether there are any blocks that have not yet been transmitted in the first patch module, until all blocks are exported and transmitted.

[0124] Furthermore, in the embodiments of this disclosure, breakpoint resumption of block transmission can also be supported. Specifically, in response to the failure of the current block transmission, the block export and transmission process can be re-executed for the same block index (or block number).

[0125] In step 330, the block data transmitted to the second patch module can be reconstructed in the temporary storage area as the internal state of the second patch module.

[0126] As an example, a streaming import interface can be implemented in the second patch module, such as: "import_state_chunk(chunk_index: u32, data:&[u8]) ->Result<(), String>". The second patch module can receive the chunks sequentially through this interface and rebuild the state internally.

[0127] In step 340, in response to confirmation that the chunked data has been correctly received, the internal state pointer of the second patch module can be switched from the temporary storage area to the formal storage area.

[0128] Specifically, after all chunks have been transmitted, the correctness of all chunks transmitted to the second patch module can be verified. Here, the correctness verification includes verification of the correctness of the chunk order and / or verification of the integrity of the chunk data.

[0129] In the block order correctness check, it can be verified whether the order of the blocks received by the second patch module is consistent with the order of the blocks exported by the first patch module. If the order is consistent, it can be confirmed that the block data has passed the block order correctness check; if the order is inconsistent, it can be confirmed that the block data has failed the block order correctness check.

[0130] In the integrity verification of chunked data, a state verification interface (e.g., verify_state()) can be called, passing in the hash value of the entire state (e.g., SHA-256). The second patch module calculates the hash of the locally reconstructed state and compares it with the hash of the state of the first patch module when it was frozen. If the hashes match, the chunked data can be confirmed to have passed the integrity verification; if the hashes do not match, the chunked data can be confirmed to have failed the integrity verification.

[0131] Once it is confirmed that the block data has been received correctly, the internal state pointer of the second patch module can be switched from the temporary storage area to the formal storage area.

[0132] Furthermore, in step 340, in response to the confirmation that the chunked data was not received correctly (e.g., it failed the correctness check of the chunk order and / or the integrity check of the chunked data), an error can be returned and the migration terminated.

[0133] In the embodiments of this disclosure, considering that the migration process must ensure complete success or complete unchangedness to prevent inconsistencies caused by partial state overwriting, as a preparation stage for state migration, in steps 310 to 330 above, the first patch module exports block data and transmits it to the second patch module. The second patch module first reconstructs the state in a temporary storage area (e.g., an independent linear memory area or temporary buffer), but does not activate it. As a submission stage for state migration, after confirming that all blocks have been received and verified, the second patch module can switch its internal state pointer from the temporary storage area to the formal storage area through an atomic operation.

[0134] In this way, the state transition through two-phase commit (2PC) can ensure that the state of the first patch module and the second patch module are consistent, so as to ensure that the service will not fail after the patch update.

[0135] In addition, after performing step 340 above, step 140 may also include: notifying the first patch module to release the frozen state and enter the silent exit mode, and updating the registry of the second patch module to mark the second patch module as active.

[0136] In addition, during the execution of step 140, it is also possible to monitor whether a failure handling condition is triggered. In response to the triggering of a failure handling condition, the state transition is stopped and a failure handling operation is performed.

[0137] For example, failure handling conditions may include at least one of the following: any chunk export or import fails (e.g., due to network timeout, insufficient memory, or verification error); version conversion fails (e.g., due to no available conversion path); or the second patch module crashes or times out during import.

[0138] Failure handling operations may include: discarding the temporary state area of ​​the second patch module and releasing memory; the first patch module exiting frozen mode and resuming normal read and write services; and logging failures to allow query commands such as the list command to view the reasons for state transition failures.

[0139] In the event of a migration failure, you can either retry the migration using the same target patch or ignore the migration and keep the first patch module running.

[0140] The above describes the process of migrating the current state data of the first patch module to the second patch module. As an example, in the above migration process, the original data of the current state data of the first patch module can be migrated directly, or the current state data of the first patch module can be transformed and the transformed data can be migrated.

[0141] As an example, such as Figure 4As shown, the above step of migrating the current state data of the first patch module to the second patch module may further include: In step 410, the version of the target patch and the version of the current active patch corresponding to the first patch module can be determined.

[0142] Specifically, the metadata of each patch may include the version number of the patch (for example, including the state_schema_version field, and the field value may be v1, v2, etc.), which can be embedded in the patch during the patch generation process. Therefore, when the first patch module exports the state, the version number of the current active patch corresponding to it is also attached.

[0143] In step 420, in response to the version of the target patch being the same as the version of the current active patch, the original data of the current state data of the first patch module can be migrated to the second patch module.

[0144] In step 430, in response to the version of the target patch being different from the version of the current active patch, the current state data of the first patch module can be transformed to obtain the transformed data; the transformed data can be migrated to the second patch module.

[0145] For example, let the state Schema version of the first patch module be V_old, and the version expected by the second patch module be V_new. If V_old == V_new, the original data of the current state data of the first patch module can be directly passed; if V_old < V_new, it can be checked whether there is a conversion chain from V_old to V_new, and multi-level upgrades can be supported in the conversion chain. If the conversion chain is found, the conversions can be applied sequentially according to the conversion chain; if the conversion chain is not found, it can be considered that the migration fails and rolls back to the state before the migration starts.

[0146] As an example, in the above step 430, the step of transforming the current state data of the first patch module to obtain the transformed data may include: determining a conversion function from the version of the current active patch to the version of the target patch according to a preset version mapping table; based on the conversion function, transforming the current state data of the first patch module to obtain the transformed data.

[0147] Specifically, a preset version mapping table can be maintained in the host program, and the version mapping table records the conversion functions from the old version Schema to the new version Schema. The conversion functions may include built-in functions of the Wasm module and / or conversion scripts pre-embedded in the host program.

[0148] Here, a built-in function of the Wasm module could be, for example, the function "transform_state(source_version,data) ->new_data". Transformation scripts pre-embedded in the host application can be pre-registered transformation scripts executed by the host application using an embedded lightweight scripting engine (such as QuickJS).

[0149] Furthermore, the aforementioned conversion process can be completed in the host program's memory without modifying the state data of the first patch module.

[0150] Furthermore, during the above conversion process, type signatures defined by WIT can be used for verification to ensure field type compatibility (e.g., u32 can be upgraded to u64, but not reversibly). Incompatible changes (e.g., deleting required fields) can be rejected, and developers can be prompted to provide explicit conversion scripts.

[0151] Migrating state data using the above method can resolve the issue of differences in state structure between different patch versions (such as field additions / deletions, type changes, and enumeration variant modifications), ensuring successful migration execution.

[0152] The above describes an example process of migrating state data from a first patch module to a second patch module. As an example, in an embodiment of this disclosure, before performing the entire state data migration process, it can also be determined whether to perform the state data migration based on the priority of the target patch (i.e., step 140 above).

[0153] As an example, the priority of the target patch can be compared with the priority of the currently active patch corresponding to the first patch module; if the priority of the target patch is higher than the priority of the currently active patch, the current state data of the first patch module is migrated to the second patch module.

[0154] For example, a live patch priority list can be configured for the host program. The active patch list (UPN) can include a head, which stores the priority information of currently active patches. Active patch instances can be directly attached to the function pointer of the requesting router. The UPN can also include successor nodes linked to the head. Next nodes store the priorities of backup patches with lower priorities than the currently active patch; these could be backup patch instances in a pre-heated or frozen state. Each patch node contains a version number and a priority parameter. (For example (The smaller the value, the higher the priority) and running status. Here, in the patch priority list, the successor node is not required, and the patch priority list may not include a successor node.

[0155] Before performing state data migration, the priorities of the target patch of the first patch module and the currently active patch of the second patch module can be compared. State data migration is only performed if the priority of the target patch is higher than that of the currently active patch. If the priority of the target patch is lower than or equal to that of the currently active patch, the second patch module can be used as a backup patch module for the first patch module and the patch update can be terminated.

[0156] Furthermore, as an example, the patch update method may also include: if the priority of the target patch is higher than the priority of the currently active patch, replacing the priority information of the currently active patch stored in the head of the preset patch priority linked list with the priority information of the target patch; if the priority of the target patch is lower than or equal to the priority of the currently active patch, using the second patch module as a backup patch module for the first patch module, exiting the patch update, and creating a successor node linked to the head of the linked list, wherein the priority information of the target patch is stored in the successor node.

[0157] Specifically, if the target patch has a higher priority than the currently active patch, the second patch module will be used to update the first patch module. The target patch will then become the active patch after the update. Therefore, the priority information stored at the head of the priority linked list can be updated to store the target patch as the active patch. If the target patch has a priority lower than or equal to the current active patch, a successor node linked to the head of the linked list can be created, and the priority information of the target patch can be stored in the successor node.

[0158] For example, let the currently active patch be... The newly loaded target patch is If the priority comparison result is: This can trigger the linked list hot management process, making the target patch... Seize execution rights. If the priority comparison result is: This can make the target patch Enter silent hot standby mode and attach it to the secondary node of the linked list.

[0159] By setting up the priority list mentioned above, priority management of patches can be achieved, so as to adaptively decide whether to execute the patch update process and avoid executing incorrect updates.

[0160] The above describes an example process of receiving the target patch, instantiating the second patch module, and migrating the state data of the first patch module to the second patch module. After the state data migration is completed, the internal states of the first patch module and the second patch module can be consistent. They can be used to process business requests for the host program in parallel until all existing requests are processed, and then the switch of the patch module is officially executed.

[0161] Specifically, return to reference Figure 1 In step 150, the first patch module and the second patch module can be used to process business requests for the host program in parallel.

[0162] Here, the first patch module is used to handle business requests received before the migration begins, and the second patch module is used to handle business requests received after the migration begins.

[0163] Specifically, in this step, a smooth switch of routing traffic from the second patch module to the first patch module can be achieved through the request transition mechanism, and a zero-interruption upgrade can be achieved through the dual-instance parallel running strategy.

[0164] As an example, such as Figure 5 As shown, step 150 may include the following steps: In step 510, preset tag information can be added to the service requests received after the migration begins.

[0165] As an example, new requests can be tagged with version characteristics at the entry layer (such as CoreDNS's DNS request handler). Routers that route service requests will then direct the requests to a new sandbox based on the tags (such as Header fields or context identifiers) so that they can be processed later using a second patch module.

[0166] In step 520, during the process of the host program processing the business request sequence, the patch module to process the current business request can be selected from the first patch module and the second patch module based on whether the current business request being processed carries preset tag information.

[0167] Specifically, in response to determining that the current business request carries preset tag information, the second patch module is used to process the current business request; in response to determining that the current business request does not carry preset tag information, the first patch module is used to process the current business request.

[0168] Here, uninterrupted service for business requests can be achieved through parallel processing of dual instances. On the one hand, the second patch module receives and processes requests marked as new versions and executes new business logic; on the other hand, the first patch module continues to process existing requests until all active requests are processed, during which time new requests are rejected.

[0169] In addition, as an example, during the parallel processing described above, the latency, error rate, and resource consumption of the old and new modules can be continuously monitored, and a rollback can be triggered immediately if the second patch module encounters an anomaly.

[0170] In step 160, in response to the completion of processing of all business requests received before the migration began, the first patch module can be uninstalled and the second patch module can be used as the updated first patch module.

[0171] As an example, an active request counter for the first patch module can be maintained. This could be an atomic counter, incremented or decremented atomically to precisely track the number of requests the first patch module is processing. The active request counter can be queried periodically. For instance, if the counter reaches zero (i.e., all outstanding requests are cleared) and this continues for a full timeout period (e.g., twice the maximum request processing time), it can be confirmed that the first patch module has no outstanding requests. For example, a hook function such as `shutdown()` can be triggered to release the Wasm sandbox where the first patch module resides, completely avoiding the connection loss issues caused by traditional hang-up (HUP) signals, notifying it to prepare for exit. The first patch module can then perform resource cleanup (e.g., closing connections, flushing buffers, and releasing handles).

[0172] In addition, as an example, if the first patch module fails to exit within the configured timeout period (e.g., 30 seconds), the first patch module instance can be forcibly terminated to prevent zombie processes.

[0173] As an example, the second patch module can be used as the updated first patch module in the following way: use an atomic operation (Compare-And-Swap) to switch the request route pointer, and use the operating system's atomic patch switching request to switch the route pointer from the first patch module to the second patch module, completing the logical jump in nanoseconds to ensure that there is no request loss or race condition during the switching process.

[0174] In addition, as an example, after confirming that the first patch module has completely exited, its linear memory space, AOT compilation cache, file descriptors, and other resources are reclaimed.

[0175] Furthermore, as an example, after making the second patch module the first patch module after the update, the current version information of the module registry can be updated, the upgrade completion timestamp can be recorded, and a notification event can be sent.

[0176] Furthermore, in step 160 above, this can be achieved by executing "uos-wasmpluginunload".<module_name> "When uninstalling a Wasm patch, the system no longer simply stops the current patch; instead, it automatically searches the hot patch list for the second-highest priority Wasm module in 'warm-up mode' or 'frozen mode.' After uninstallation, it executes the highest-priority patch in the Wasm patch list."

[0177] In response, if the current patch module is stateful, uninstallation will trigger a reverse state transition interface (e.g., synchronizing the incremental data of the target patch back to the old or backup version), and then execute hook functions such as shutdown() to release linear memory and AOT compilation handles, ensuring that after uninstallation the system not only restores the code, but also restores to the correct data state, which is something that traditional patch updates cannot achieve.

[0178] The patch update method according to embodiments of the present disclosure has been described above. As an example, after performing the steps of uninstalling the first patch module and using the second patch module as the updated first patch module, the patch update method may further include the following steps: Determine the first runtime error rate of the uninstalled first patch module, the first resource consumption required by the uninstalled first patch module, the second runtime error rate of the updated first patch module, and the second resource consumption required by the updated first patch module; Based on the priority, first runtime error rate, and first resource consumption of the uninstalled first patch module, determine the first score of the uninstalled first patch module; The second score of the updated first patch module is determined based on the priority of the updated first patch module, the second runtime error rate, and the second resource consumption. If the first rating is lower than the second rating, update the first patch module described above with the uninstalled first patch module.

[0179] Here, the updated first patch module is the same as the second patch module mentioned above. After the updated first patch module is officially running, the error rate and resource consumption of the patch module can be continuously monitored.

[0180] As an example, when each patch module is active, its runtime error rate and resource consumption deviation rate can be statistically recorded. Even if the patch module is uninstalled, its priority, recorded runtime error rate, and resource consumption deviation rate are still saved. Thus, during the operation of the host program, in response to receiving an update command from a user (e.g., an administrator), the score of the currently active patch module can be compared with the score of a historical patch module (e.g., the uninstalled first patch module) (e.g., the aforementioned score S). If the score of the currently active patch module is greater than or equal to the score of the historical patch module, the currently active patch module can continue to be retained and used. If the score of the currently active patch module is less than the score of the historical patch module, the historical patch module can be used to update the currently active patch module, or it can be reloaded back into the historical patch module. For example, the historical patch module can be used as the second patch module in step 140 above, and the update can be performed starting from the state data migration, migrating the state data of the currently active patch module to the historical patch module.

[0181] Here, the priority of a patch module can be determined based on the priorities of the patches it contains. For example, the priority of a patch module can be the average of the priorities of the patches it contains.

[0182] Specifically, the scores of the two patch modules can be comprehensively evaluated based on their priorities, runtime error rates, and resource consumption, respectively, so as to adaptively apply the better patch module.

[0183] As an example, the score of a patch module can be determined by the following formula (1): (1) in, This indicates the rating of the patch module. Indicates the priority of the patch module. This indicates the error rate of the patch module (e.g., it could be derived from health check data). This indicates the resource consumption deviation rate of the patch module, which can represent CPU utilization. , and This indicates the preset weight. Here, the resource consumption deviation rate can be obtained by comparing the resource consumption of the patch module with the preset resource consumption baseline. As an example, the resource consumption baseline here can be set according to actual needs, for example, it can be the same as the preset baseline in the resource exhaustion verification above.

[0184] Using the above method, the node with the best rating in the patch module can be automatically set as the target of the current routing pointer, thereby achieving automatic version switching based on the running status.

[0185] The patch update method according to embodiments of this disclosure can provide a Wasm-based hot patching tool (e.g., named uos-wasmplugin) that enables uninterrupted, high-performance, and securely isolated online upgrades.

[0186] Specifically, this method utilizes a smooth transition mechanism to ensure uninterrupted service during upgrades, achieving zero downtime. Furthermore, it employs a dual-instance parallelism and graceful exit strategy to ensure no request loss or connection interruption during the upgrade process. Compared to the traditional HUP signaling mechanism, it avoids connection drops caused by worker process restarts.

[0187] Furthermore, this method leverages Wasm linear memory isolation and structured control flow, with each module running in an independent sandbox to prevent unauthorized access by patch code, achieving secure sandbox isolation. Specifically, memory access is checked for boundary conditions to prevent buffer overflows, and host memory is inaccessible unless accessed through explicitly imported host functions. Additionally, control flow security prevents arbitrary jumps and ROP attacks, and a digital signature mechanism ensures the trustworthiness of patch sources.

[0188] Furthermore, this method utilizes AOT compilation technology to achieve near-native code execution efficiency for the Wasm module, resulting in high-performance execution. Specifically, using Wazero's AOT compilation technology, the Wasm module is compiled into machine code at load time, achieving execution efficiency close to native C code (typically 60-80% of native performance), far exceeding Lua interpreted execution, while avoiding a full restart and eliminating cache warm-up overhead.

[0189] Furthermore, this method supports state transitions for stateful modules, ensuring no loss of business data, supports smooth transitions for stateful modules, ensures the continuity of state during patch module switching, and ensures that connection pools, caches, and other states are not lost.

[0190] Furthermore, this method supports online switching of patch execution strategies using a list approach. Specifically, patch priority and switching strategies can be adjusted online using the `list` and `reload` commands, and the `unload` command enables seamless uninstallation and automatic switching, greatly improving operational flexibility.

[0191] Furthermore, this method allows for patch writing in multiple languages ​​such as Rust, Go, and C / C++ through the Wasm interface definition, meeting the needs of different team technology stacks.

[0192] Figure 6 An example architecture for implementing a patch update method according to an exemplary embodiment of this disclosure is shown.

[0193] like Figure 6 As shown, this framework can serve as a Wasm hot patch management tool, uos-wasmplugin (UOSWebAssembly Hot Patching Tool), employing a layered architecture design to achieve full lifecycle management of patches. Specifically, the framework can include five layers.

[0194] At management level 610, six core commands can be provided: build, verify, load, unload, reload, and list, to manage the entire lifecycle of hot patches.

[0195] At the interface layer 620, module management, patch upload, status query, and patch uninstallation can be implemented. For example, relevant interfaces for module management, patch upload, status query, and patch uninstallation for rollback control can be exposed through RESTful / RPC management APIs.

[0196] At runtime layer 630, the Wasm runtime can be implemented based on Wazero, which may include an AOT compiler, sandbox executor, isolated memory manager and concurrent scheduler to ensure efficient and safe execution of modules.

[0197] The Module Lifecycle Manager 640 enables the coexistence and switching of first patch module and second patch module instances, and achieves uninterrupted upgrades through state migraters and request routers.

[0198] At the host application layer 650, the target service process (such as CoreDNS) can integrate the WIT standard interface, call the host function to process business logic, and dynamically load the Wasm module through configuration management.

[0199] The above architecture enables the complete process of patch creation, local verification, online upgrade, state pre-migration, request transition, patch switching, and patch uninstallation in the methods of the embodiments of this disclosure, and has the characteristics of high performance, security isolation, and zero-disruption upgrade.

[0200] Figure 7 An application example of a patch update method according to exemplary embodiments of the present disclosure is shown. In this example, the host program is a CoreDNS process, which can implement CoreDNS hot patch updates based on the Wazero runtime by executing the patch update method according to embodiments of the present disclosure.

[0201] Specifically, the following environment can be prepared: CoreDNS v1.11+, which has integrated Wazero v1.0+ as the Wasm runtime; implement the standard WIT interface definition (dns_plugin.wit), including functions such as process_query, health_check, export_state, import_state, verify_state, and shutdown; configure the Corefile to enable the wasm plugin, specifying the module directory and API listening address.

[0202] In step 710, patch creation can be performed. For example, developers can write a DNS query logging module, implemented in Rust, with sample code as follows: / / log_processor.rs wit_bindgen::generate!({ world:"dns-plugin", path:"dns_plugin.wit" }); struct LogPlugin; impl Guest for LogPlugin { fn process_query(query: Query) ->Response { / / Record query logs host::log(&format!("Query: {:?} from {}", query.name, query.client_ip)); / / Continue with follow-up processing Response::pass_through() } fn health_check() ->HealthStatus { HealthStatus::healthy() } fn init() ->Result<(), String>{ / / Initialize the log connection pool, etc. Ok(()) } fn shutdown() { / / Clean up resources }}".

[0203] Furthermore, an example of a compilation command used to compile user-provided source code to generate a Wasm module could be as follows: "uos-wasmplugin build --input log_processor.rs \ --output dns_log.whp --wit dns_plugin.wit \ --version 1.0.0 \ --priority 50 \ --sign-key signing.key” In addition, based on the compiled Wasm module, a standard patch package (e.g., the dns_log.whp file) can be generated as the target patch. This patch package can include the Wasm module, WIT definition, metadata, and Ed25519 signature. The metadata can include version v1.0.0, priority 50, state schema version, build timestamp, and WIT interface hash.

[0204] In step 720, local verification can be performed on the second patch module instantiated based on the target patch. Specifically, the second patch module can be pre-verified in a local sandbox environment. A code example for pre-verification is as follows: "uos-wasmplugin verify --input dns_log.whp \ --host-api dns_plugin.wit \ --test-script . / dns_test.js \ --perf-threshold 20".

[0205] After performing the verification, a verification report can be generated. An example of such a report is as follows: json { "signature":"passed", "interface_compat":"passed", "functional": {"passed": 12,"failed": 0}, "security": {"passed": 5,"warnings": 0}, "performance": {"latency_us": 45,"baseline_us": 42,"degradation":"7%"} }".

[0206] In step 730, an online upgrade of the second patch module can be performed. Specifically, a separate, isolated linear memory space can be allocated on the CoreDNS node, such as the following: "uos-wasmplugin load coredns-log harbor.uos.io / dns-plugins / dns_log:v1.0.0 \ --host coredns-01.internal".

[0207] Here, after the Wasm plugin in the CoreDNS process receives a memory page table request, it can perform transient instantiation and AOT warm-up within a sandbox. Specifically, an independent sandbox can be created, and the Wasm module can be compiled into machine code via AOT compilation. This compilation process does not consume CPU time slices from the business logic. Furthermore, the init() function can be called for warm-up without connecting to traffic. In this state, restricted host function call tests can be performed to confirm that the health check function health_check() is ready. At this point, the second patch module can be added to the hot patch list with a priority of 50 (if its priority is lower than the currently active module's priority of 30, only warm-up is performed; if its priority is higher than the currently active module's priority of 30, a state transition is triggered).

[0208] In step 740, a state pre-transition can be performed (if the first patch module has a state). Specifically, assuming the priority of the currently active first patch module is 30 (lower values ​​indicate higher priority), and the priority of the second patch module is 50 (lower), then the state transition is skipped, and the second patch module is only used as a backup. If the priority of the second patch module is 20 (higher), then the transition is triggered.

[0209] Specifically, the first patch module can call export_state() to export query records from the DNS cache; the host converts the old cache format to the new format based on the state schema mapping table; the second patch module calls import_state() to import cache data in chunks; and verify_state() is called to verify the consistency of the cache hit rate. If the verification passes, the first patch module enters the "frozen" state, and the second patch module is marked as "state ready".

[0210] When a target patch is loaded into the hot patch list via commands such as load or reload, the system can determine whether a state transition needs to be performed based on a priority decision model: if the priority of the target patch is higher than that of the currently active module, the state transition process is triggered; otherwise, it is skipped, and the second patch module exists only as a backup or low-priority module.

[0211] Here, for stateful first patch modules (such as connection pools, caches, session states, counters, etc.), an enhanced state migration mechanism can be provided, which includes four sub-mechanisms: frozen checkpoints, chunked transmission, schema version compatibility, and atomic rollback, to ensure the consistency and reliability of the migration process.

[0212] In step 750, a business request transition (or traffic switching) can be performed. Specifically, new requests can be colored (e.g., by adding the marker "Header X-Wasm-Version:new") at the request entry point where the host program receives business requests, so that they are routed to the second patch module for processing. Here, the first patch module enters read-only mode and only processes existing requests (e.g., by tracking them using atomic counters).

[0213] In addition, during the processing of business requests, the latency and error rate of the second patch module can be monitored (with no abnormalities for 30 seconds). After the existing requests are reduced to zero, the shutdown() function of the first patch module can be called to release sandbox resources and atomically switch the routing pointer (CAS operation) to the second patch module to complete the upgrade of the patch module.

[0214] In step 760, the patch module can be uninstalled, and a new patch module can be switched to and a health check performed. For example, the current list of hot patch modules can be viewed using "uos-wasmplugin list coredns-log --hostcoredns-01.internal", and the update results can be output. An example of the update results is as follows: Module: coredns-log Active version: 1.0.0 (priority 50, state: running) Standby versions: - 0.9.0 (priority 30, state: frozen) Last migration: 2026-04-07T10:30:00Z, checksum matched”.

[0215] In addition, during the above process, patches can be updated based on their running scores (e.g., reactivating older versions of patches). For example, you can execute "uos-wasmplugin reload coredns-log --priority 20 --host coredns-01.internal", and the system will automatically re-execute from step 740, the state transition, to activate the version with priority 20.

[0216] The patch update method according to the exemplary embodiments of this disclosure can achieve uninterrupted hot patching and linear memory isolation based on Wasm. It can cover a complete toolchain including patch creation (including signing and metadata injection), multi-channel distribution (OCI / HTTP / local), online upgrade (sandbox loading, health checks), and status verification, realizing standardized management of the patch lifecycle. This differs from traditional binary (JAR package) replacement or class loader updates, as this method can allocate independent linear memory space within the host process and utilize the memory page table mechanism to achieve physical isolation between patches.

[0217] Furthermore, the patch update method according to the exemplary embodiments of this disclosure can achieve heterogeneous state schema version compatibility and automated conversion mechanisms. By employing a dual-instance parallel execution strategy, combined with existing request tracing and graceful exit mechanisms, and completing data format upgrade / downgrade adaptation during the migration process, business logic continuity is ensured, achieving true zero-downtime upgrades. In addition, standard state migration interfaces (e.g., export_state / import_state) can be defined to support seamless upgrades of stateful services. Resource exhaustion testing and isolation illegal call interception verification are added to intercept risks before production loading.

[0218] Furthermore, the patch update method according to the exemplary embodiments of this disclosure can implement a large-state block atomic migration protocol based on two-phase commit (2PC). Specifically, it solves the service blocking and memory spike problems caused by large-scale memory state migration by using block streaming transmission, combined with a two-phase atomic operation of "freeze-export-verify-commit". In the event of migration failure, a temporary storage area rollback mechanism is used to ensure that the old module immediately exits the frozen mode, ensuring that the system does not crash due to upgrade failure.

[0219] Furthermore, the patch update method according to the exemplary embodiments of this disclosure can implement a zero-disruption switching mechanism based on request coloring and atomic pointer redirection. For example, request coloring technology is used to version-label traffic, and CAS (Compare-And-Swap) atomic patching is used to switch request routing pointers. In addition, an atomic counter for existing requests can be introduced to ensure that the old module is only triggered to unload after all active requests gracefully reach zero, achieving a truly uninterrupted TCP connection upgrade.

[0220] Furthermore, the patch update method according to the exemplary embodiments of this disclosure can be based on Wazero's AOT compilation patch instantaneous instantiation mechanism and lightweight runtime. Specifically, the AOT compilation capability of the Wazero runtime can be utilized to generate machine code when the module is loaded, balancing startup speed and execution performance. The zero CGO dependency design ensures the portability and deployment convenience of the toolchain.

[0221] Furthermore, the patch update method according to the exemplary embodiments of this disclosure can implement priority list management, supporting the simultaneous loading of multiple functional patches by maintaining a patch priority list. Priorities can be dynamically adjusted using commands such as `reload`, automatically triggering state transitions and enabling "online rollback" or "canary rollover" of patch versions without re-executing the loading process.

[0222] In a second aspect of exemplary embodiments of this disclosure, a patch update apparatus is provided, such as Figure 8 As shown, the patch update device 800 may include a receiving unit 810, an instantiation unit 820, an allocation unit 830, a migration unit 840, a processing unit 850, and an update unit 860.

[0223] The receiving unit 810 is configured to receive a target patch for updating a first patch module in the host program, wherein the target patch includes the Wasm module.

[0224] Instantiation unit 820 is configured to instantiate the target patch in the Wasm sandbox environment to obtain the second patch module, wherein the Wasm sandbox environment is the same as the production environment in which the host program is located.

[0225] The allocation unit 830 is configured to allocate memory space for the second patch module in the Wasm sandbox environment.

[0226] The migration unit 840 is configured to migrate the current state data of the first patch module to the second patch module if state data exists in the first patch module.

[0227] The processing unit 850 is configured to process business requests for the host program in parallel using a first patch module and a second patch module, wherein the first patch module is used to process business requests received before the migration begins, and the second patch module is used to process business requests received after the migration begins.

[0228] Update unit 860 is configured to unload the first patch module and use the second patch module as the updated first patch module in response to the completion of processing of all business requests received before the migration begins.

[0229] As an example, the migration unit 840 is configured to: compare the priority between the target patch and the currently active patch corresponding to the first patch module; if the priority of the target patch is higher than the priority of the currently active patch, migrate the current state data of the first patch module to the second patch module; if the priority of the target patch is lower than or equal to the priority of the currently active patch, use the second patch module as a backup patch module for the first patch module and exit the patch update.

[0230] As an example, the patch update device also includes a priority management unit configured to: replace the priority information of the current active patch stored in the head of a preset patch priority linked list with the priority information of the target patch when the priority of the target patch is higher than the priority of the current active patch; and create a successor node linked to the head of the linked list and store the priority information of the target patch in the successor node when the priority of the target patch is lower than or equal to the priority of the current active patch.

[0231] As an example, the patch update apparatus further includes a scoring unit configured to: determine a first runtime error rate of the uninstalled first patch module, a first resource consumption of the uninstalled first patch module, a second runtime error rate of the updated first patch module, and a second resource consumption of the updated first patch module; determine a first score of the uninstalled first patch module based on the priority of the uninstalled first patch module, the first runtime error rate, and the first resource consumption; determine a second score of the updated first patch module based on the priority of the updated first patch module, the second runtime error rate, and the second resource consumption; and update the updated first patch module with the uninstalled first patch module if the first score is lower than the second score.

[0232] As an example, the patch update device also includes a verification unit configured to: perform health checks and resource consumption verification on the second patch module in a Wasm sandbox environment; in response to the second patch module passing the health check and resource consumption verification, cause the migration unit 840 to perform the step of migrating the current state data of the first patch module to the second patch module if state data exists in the first patch module, wherein the health check includes: checking the runtime error rate of the second patch module, wherein the resource consumption verification includes: verifying the resource consumption required to execute the second patch module through patch injection; in response to the deviation of resource consumption from a preset baseline exceeding a preset threshold, determine that the second patch module has failed the resource consumption verification; in response to the deviation not exceeding the preset threshold, determine that the second patch module has passed the resource consumption verification.

[0233] As an example, migration unit 840 is configured to: freeze the first patch module; export the current state data of the first patch module in blocks and transmit it to the second patch module; reconstruct the block data transmitted to the second patch module as the internal state of the second patch module in a temporary storage area; and switch the internal state pointer of the second patch module from the temporary storage area to the formal storage area in response to confirmation that the block data has been correctly received.

[0234] As an example, migration unit 840 is configured to: determine the version of the target patch and the version of the currently active patch corresponding to the first patch module; in response to the version of the target patch being the same as the version of the currently active patch, migrate the original data of the current state data of the first patch module to the second patch module; in response to the version of the target patch being different from the version of the currently active patch, transform the current state data of the first patch module to obtain transformed data; and migrate the transformed data to the second patch module.

[0235] As an example, migration unit 840 is configured to: determine a conversion function from the version of the currently active patch to the version of the target patch according to a preset version mapping table, wherein the conversion function includes built-in functions of the Wasm module and / or conversion scripts pre-embedded in the host program; and based on the conversion function, convert the current state data of the first patch module to obtain the converted data.

[0236] As an example, the processing unit 850 is configured to: add preset tag information to the service requests received after the migration begins; during the process of the host program processing the service request sequence, select a patch module from the first patch module and the second patch module to process the current service request based on whether the current service request carries preset tag information, wherein, in response to determining that the current service request carries preset tag information, the second patch module is used to process the current service request, and in response to determining that the current service request does not carry preset tag information, the first patch module is used to process the current service request.

[0237] According to the patch update apparatus of the embodiments of this disclosure, when updating the first patch module in the host program, the target patch can be instantiated in the Wasm sandbox environment to obtain the second patch module without stopping the first patch module. Memory space is allocated for the second patch module in the sandbox environment, and the state data of the first patch module is migrated to the second patch module. Then, the first patch module and the second patch module can be used to process business requests for the host program in parallel until all existing requests for the first patch module are processed. The second patch module then officially replaces the first patch module. In this way, the switching of patch modules can be completed without service interruption and without the user's awareness, realizing zero-interruption patch updates. Furthermore, the logic of the second patch module is restricted to the boundary of linear memory in the Wasm sandbox and cannot escape into the address space of the host program, ensuring the normal operation of the host program and preventing the host program's data from being tampered with without authorization.

[0238] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs the operation has been described in detail in the embodiments related to the method. Each unit in the apparatus can perform the corresponding steps in the method according to the patch update method in the method embodiment of the first aspect above and achieve the corresponding beneficial effects, which will not be described in detail here.

[0239] In a third aspect of exemplary embodiments of the present disclosure, a computing device is provided, the computing device including: a processor; and a memory for storing computer-executable instructions, wherein the computer-executable instructions, when executed by the processor, cause the processor to perform a patch update method according to the present disclosure.

[0240] Figure 9 This is an example block diagram of a computing device according to exemplary embodiments of the present disclosure. Figure 9As shown, the computing device 900 may include a processor 910 and a memory 920, which may be used to store computer-executable instructions 921 and an operating system 922. Here, when the computer-executable instructions are executed by the processor 910, they cause the processor 910 to perform a patch update method as described in the exemplary embodiment above. The computer-executable instructions 921 may run together with the operating system 922 in the processor.

[0241] As an example, computing device 900 is not necessarily a single device, but can be a collection of any means or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Computing device 900 can also be part of an integrated control system or system manager, or can be configured to interconnect with a server locally or remotely (e.g., via wireless transmission) through an interface.

[0242] In computing device 900, processor 910 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 910 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0243] The processor 910 can execute instructions or code stored in the memory 920, which can also store data. Instructions and data can also be sent and received via a network through a network interface device, which can employ any known transmission protocol.

[0244] The memory 920 may be integrated with the processor 910, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 920 may include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 920 and the processor 910 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 910 to read files stored in the memory 920.

[0245] In addition, the computing device 900 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the computing device 900 can be interconnected via a bus and / or network.

[0246] In an exemplary embodiment, a computer-readable storage medium may also be provided, which, when executed by a processor of a computing device, enables the computing device to perform the patch update method as described in the exemplary embodiment above. The computer-readable storage medium may be, for example, a memory including instructions. Optionally, the computer-readable storage medium may be: a read-only memory (ROM), a random access memory (RAM), a random access programmable read-only memory (PROM), an electrically erasable programmable read-only memory (EEPROM), a dynamic random access memory (DRAM), a static random access memory (SRAM), flash memory, non-volatile memory, a CD-ROM, a CD-R, a CD+R, a CD-RW, a CD+RW, a DVD-ROM, a DVD-R, a DVD+R, a DVD-RW, a DVD+RW, a DVD-RAM, a BD-ROM, a BD-R, or a BD-R... LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store computer programs and any associated data, data files, and data structures in a non-transitory manner and to provide the computer programs and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer programs. The computer programs in the aforementioned computer-readable storage media can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer programs and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer programs and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0247] According to exemplary embodiments of the present disclosure, a computer program product may also be provided, the computer program product including computer-executable instructions that, when executed by at least one processor, implement a patch update method according to exemplary embodiments of the present disclosure.

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

[0249] Furthermore, it should be noted that although several examples of each step have been described above with reference to the specific accompanying drawings, it should be understood that the embodiments of this disclosure are not limited to the combinations given in the examples. The steps appearing in different drawings can be combined, and the execution order of each step can be changed, which will not be exhaustive here.

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

Claims

1. A patch update method, characterized in that, The patch update method includes: Receive a target patch for updating a first patch module in the host program, wherein the target patch includes a Wasm module; The target patch is instantiated in the Wasm sandbox environment to obtain the second patch module, wherein the Wasm sandbox environment is the same as the production environment in which the host program is located; In the Wasm sandbox environment, memory space is allocated for the second patch module; If the first patch module has status data, the current status data of the first patch module will be migrated to the second patch module; The first patch module and the second patch module are used to process business requests for the host program in parallel. The first patch module is used to process business requests received before the migration starts, and the second patch module is used to process business requests received after the migration starts. Upon completion of processing of all service requests received prior to the start of the migration, the first patch module is uninstalled, and the second patch module is used as the updated first patch module. Wherein, allocating memory space for the second patch module in the Wasm sandbox environment includes: During the Wasm runtime, a target linear memory space is allocated for the second patch module in the Wasm sandbox environment, wherein the target linear memory space is physically independent of the process address space of the host program; Configure a permission mask for the target linear memory space, wherein the permission mask is used to physically restrict the instruction flow of the second patch module to a preset page table range within the linear memory space.

2. The patch update method according to claim 1, characterized in that, The step of migrating the current state data of the first patch module to the second patch module includes: Compare the priority of the target patch with the currently active patch corresponding to the first patch module; If the priority of the target patch is higher than the priority of the currently active patch, the current status data of the first patch module is migrated to the second patch module; If the priority of the target patch is lower than or equal to the priority of the currently active patch, the second patch module is used as a backup patch module for the first patch module, and the patch update is terminated.

3. The patch update method according to claim 2, characterized in that, The patch update method also includes: If the priority of the target patch is higher than the priority of the currently active patch, the priority information of the currently active patch stored in the head of the preset patch priority list is replaced with the priority information of the target patch. If the priority of the target patch is lower than or equal to the priority of the currently active patch, a successor node linked to the head of the linked list is created, and the priority information of the target patch is stored in the successor node.

4. The patch update method according to claim 1, characterized in that, After performing the steps of uninstalling the first patch module and using the second patch module as the updated first patch module, the patch update method further includes: Determine the first runtime error rate of the uninstalled first patch module, the first resource consumption of the uninstalled first patch module, the second runtime error rate of the updated first patch module, and the second resource consumption of the updated first patch module; Based on the priority of the uninstalled first patch module, the first runtime error rate, and the first resource consumption, a first score is determined for the uninstalled first patch module; Based on the priority of the updated first patch module, the second runtime error rate, and the second resource consumption, a second score for the updated first patch module is determined. If the first score is lower than the second score, the updated first patch module is updated using the uninstalled first patch module.

5. The patch update method according to claim 1, characterized in that, After performing the step of instantiating the target patch in the Wasm sandbox environment to obtain the second patch module, the patch update method further includes: The second patch module is subjected to a health check and resource consumption verification in the Wasm sandbox environment. In response to the second patch module passing the health check and resource consumption verification, the step of migrating the current state data of the first patch module to the second patch module, if state data exists in the first patch module, is executed. The health check includes checking the runtime error rate of the second patch module. The resource consumption verification includes: Verify the resource consumption required to execute the second patch module through patch injection; If the deviation of the resource consumption from the preset baseline exceeds a preset threshold, it is determined that the second patch module has failed the resource consumption verification. In response to the deviation not exceeding the preset threshold, the second patch module is determined to have passed the resource consumption verification.

6. The patch update method according to claim 1, characterized in that, The step of migrating the current state data of the first patch module to the second patch module includes: Freeze the first patch module; The current status data of the first patch module is exported in blocks and transmitted to the second patch module; In the temporary storage area, the block data transmitted to the second patch module is reconstructed as the internal state of the second patch module; In response to confirmation that the segmented data has been correctly received, the internal state pointer of the second patch module is switched from the temporary storage area to the formal storage area.

7. The patch update method according to claim 1, characterized in that, The step of migrating the current state data of the first patch module to the second patch module includes: Determine the version of the target patch and the version of the currently active patch corresponding to the first patch module; In response to the fact that the version of the target patch is the same as the version of the currently active patch, the original data of the current state data of the first patch module is migrated to the second patch module; In response to the difference between the version of the target patch and the version of the currently active patch, the current state data of the first patch module is transformed to obtain the transformed data; The converted data is then migrated to the second patch module.

8. The patch update method according to claim 7, characterized in that, The process of converting the current state data of the first patch module to obtain the converted data includes: Based on a preset version mapping table, a conversion function is determined from the version of the currently active patch to the version of the target patch, wherein the conversion function includes built-in functions of the Wasm module and / or conversion scripts pre-embedded in the host program; Based on the conversion function, the current state data of the first patch module is converted to obtain the converted data.

9. The patch update method according to claim 1, characterized in that, The parallel processing of business requests for the host program using the first patch module and the second patch module includes: Add preset tag information to service requests received after the migration begins; During the process of the host program processing the sequence of service requests, a patch module is selected from the first patch module and the second patch module to process the current service request, based on whether the current service request carries the preset marker information. Specifically, in response to determining that the current service request carries the preset marker information, the second patching module processes the current service request. In response to determining that the current service request does not carry the preset tag information, the first patch module is used to process the current service request.

10. A patch update device, characterized in that, The patch update device includes: The receiving unit is configured to receive a target patch for updating a first patch module in the host program, wherein the target patch includes a Wasm module; An instantiation unit is configured to instantiate the target patch in a Wasm sandbox environment to obtain a second patch module, wherein the Wasm sandbox environment is the same as the production environment in which the host program is located. The allocation unit is configured to allocate memory space for the second patch module in the Wasm sandbox environment; The migration unit is configured to migrate the current state data of the first patch module to the second patch module when the first patch module has state data. The processing unit is configured to process service requests for the host program in parallel using the first patch module and the second patch module, wherein the first patch module is used to process service requests received before the migration begins, and the second patch module is used to process service requests received after the migration begins. The update unit is configured to, in response to the completion of processing of all service requests received before the start of the migration, unload the first patch module and use the second patch module as the updated first patch module.

11. A computing device, characterized in that, The computing device includes: processor; Memory used to store executable instructions for a computer. Wherein, when the computer-executable instructions are executed by the processor, they cause the processor to execute the patch update method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of a computing device, the computing device is able to perform the patch update method according to any one of claims 1 to 9.

13. A computer program product comprising computer-executable instructions, characterized in that, When the computer-executable instructions are executed by at least one processor, they implement the patch update method according to any one of claims 1 to 9.

Images