A system plug-in hot loading method, system and computer readable storage medium

Abstract

The embodiment of the application discloses a system plug-in hot loading method, system and computer readable storage medium. The method comprises the following steps: receiving a loading request of a plug-in to be loaded; checking whether the identification of the plug-in and / or the version corresponding to the plug-in is in an engine built-in white list; and / or verifying a digital signature attached to the plug-in by using an asymmetric cryptographic algorithm; if the plug-in is in the white list and / or the digital signature is verified, the following compiling step is executed; when compiling the code of the plug-in, a corresponding capability type is generated according to the permission declared in the plug-in manifest; when the capability type is checked, it is verified whether the plug-in calling an extension point API holds a matching capability type mark, if yes, the plug-in code is compiled to realize loading. The embodiment of the application prevents overstepping operation from the structure by compiling period permission verification.

Description

Technical Field

[0001] This application relates to operating system plugin extension and compiler security technologies, and in particular to a method, apparatus, and computer-readable storage medium for hot-loading system plugins with compiler security level awareness. Background Technology

[0002] In the field of operating system plugin extensions, dynamic hot reloading of third-party plugins is a key technology for achieving flexible expansion of system functionality. Among existing technologies, Chrome Extensions (Manifest V3) is a typical hot reloading solution. This solution isolates plugins from the host process through process isolation, checks plugin permissions at runtime, and supports hot updates. However, this existing technology has significant drawbacks: plugin permissions are only checked at runtime, and such checks can be bypassed by attacks such as memory corruption and JIT spraying, failing to structurally guarantee the security of plugin permission calls. Furthermore, during hot updates, the "uninstall old plugin → load new plugin" model introduces a service interruption window of approximately 100ms. For critical system plugins such as VPNs and firewalls, even a brief service interruption can severely impact system continuity. Summary of the Invention

[0003] This application provides a system plugin hot-loading method, system, and computer-readable storage medium to solve the problems of easily bypassed permission checks and service interruption during hot updates in existing plugin hot-loading technologies.

[0004] On the one hand, the system plug-in hot-loading method provided in the embodiments of this application includes: Receive a loading request for a plugin to be loaded, check whether the plugin's identifier and / or the version corresponding to the plugin are in the engine's built-in whitelist, and / or verify the digital signature attached to the plugin using an asymmetric cryptographic algorithm; if it is in the whitelist and / or verified by digital signature, then perform the following compilation steps; When compiling the plugin's code, the corresponding capability type is generated based on the permissions declared in the plugin manifest. During capability type checking, it is verified whether the plugin calls the extension point API and holds a matching capability type tag. If so, the plugin code is compiled to enable loading.

[0005] Preferably, the compilation step specifically includes: Read the permission declarations in the plugin manifest and generate a corresponding capability type tag for each declared permission; add capability type parameters to the function signature of the system extension point API based on the capability type tags; During capability type checking, verify whether the plugin calls the system extension point API and holds a matching capability type tag. If it does, compile the plugin code; otherwise, report a compilation error.

[0006] Preferably, the method further includes: When compiling the plugin's code, a software fault isolation constraint with a specified security level is imposed on the plugin's code. A software fault isolation region address mask operation is inserted at the memory access instruction to restrict the plugin's code memory access to the software fault isolation region.

[0007] Preferably, the method further includes: During hot updates, the new version of the plugin is loaded into an independent software fault isolation area, and the extension point callback is switched from the old version of the plugin to the new version of the plugin through an atomic pointer switching operation to achieve zero service interruption updates.

[0008] Preferably, the hot update further includes an automatic rollback step during the observation period: After switching atomic pointers, the software fault isolation area of ​​the old version of the plugin is retained as a shadow state; Monitor the health metrics of the new version plugin during the observation period, including the number of crashes, extension point callback timeout rate, and / or API error rate; When the health indicator exceeds the preset threshold, the extension point callback is restored to the old version of the plugin by switching atomic pointers, and the software fault isolation area of ​​the new version of the plugin is released.

[0009] Preferably, the method further includes a fault recovery step when the plugin crashes, specifically including: When a page error is detected in the protection page of the plug-in software fault isolation area, the plug-in that has the page error is marked as crashed. Release the software fault isolation area of ​​the plugin that caused the page fault; The loading process will be re-executed after the cooldown period to restore the plugin service.

[0010] Preferably, the method further includes: before releasing the software fault isolation region of the plugin that caused the page error, when a protected page trigger page error is detected in the software fault isolation region of the plugin, checking whether the number of restarts of the plugin that caused the page error has not exceeded the maximum number of restarts declared in the plugin list; if it has not exceeded the maximum number of restarts, then performing the step of releasing the software fault isolation region of the plugin that caused the page error.

[0011] Preferably, the method further includes an extension point API versioning management step, specifically including: Before executing the compilation step, the plugin manifest declares the minimum extension point API version required; the engine verifies whether the minimum extension point API version required by the plugin declaration is not higher than the currently provided extension point API version. If it is not higher, the compilation step is executed; if it is higher, the compilation step is not executed.

[0012] On the other hand, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the aforementioned method.

[0013] Furthermore, embodiments of this application also provide a system plugin hot-loading system, which includes a plugin manager and a just-in-time compiler, wherein: The plugin manager is used to receive loading requests for plugins to be loaded, check whether the plugin identifier and / or the version corresponding to the plugin are in the engine's built-in whitelist, and / or verify the digital signature attached to the plugin using an asymmetric cryptographic algorithm; if it is in the whitelist and / or passes the digital signature verification, the just-in-time compiler is triggered. The just-in-time compiler is used to generate corresponding capability types based on the permissions declared in the plugin manifest when compiling the plugin's code; during capability type checking, it verifies whether the plugin calls the extension point API and holds a matching capability type tag. If so, the plugin code is compiled to enable loading.

[0014] The technical solution of this application structurally prevents unauthorized operations through compile-time permission verification, reduces plugin runtime overhead through SFI isolation, and achieves zero-interruption hot updates through atomic switching. Furthermore, the technical solution of this application also possesses automatic rollback and crash recovery capabilities, significantly improving the security, continuity, and stability of plugin hot loading. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating the system plug-in hot-loading method according to an embodiment of this application; Figure 2 This application provides a system architecture diagram for hot-loading of system plugins in an embodiment. Figure 3 This is a block diagram of the system structure for hot-loading of system plug-ins provided in an embodiment of this application. Detailed Implementation

[0016] The technical solution of this application will be clearly and completely described below with reference to the concepts in the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0017] As mentioned earlier, taking Chrome Extensions (Manifest V3) as an example, the core logic of existing hot-loading plugin technology is to run each plugin in an independent extension process. This process isolation isolates the plugin from the browser's main process. Permission management relies on runtime permission interception mechanisms; when a plugin attempts to call a specific API, the browser checks if the plugin has declared the corresponding permissions. If not, the call is blocked. However, this runtime permission checking model has a fundamental flaw: attackers can exploit memory corruption vulnerabilities to tamper with the plugin process's memory data, bypassing the permission checking logic; or they can use JIT (Just-In-Time) spraying technology to construct malicious instruction sequences and directly execute unauthorized operations. Furthermore, the Chrome Extensions hot-update process is "stop the old plugin process → unload the old plugin resources → load the new plugin code → start the new plugin process." This process inevitably generates a service interruption window of approximately 100ms. For critical system plugins such as VPNs and firewalls that require continuous operation, this interruption can lead to network connection disruptions and security failures. Meanwhile, Chrome Extensions uses process isolation, with each plugin process requiring approximately 50MB of memory and inter-process communication (IPC) latency of approximately 10μs. In high-frequency extension scenarios (such as network filtering per packet), the memory and performance overhead is too high, failing to meet the performance requirements of system-level plugins.

[0018] To address the technical problems existing in the prior art, embodiments of this application provide a compiler security level-aware system plugin hot-loading method. See also Figure 1 The diagram illustrates the flowchart of this embodiment, and the specific execution steps are as follows: Step S11: Receive the loading request of the plugin to be loaded, and perform whitelist access verification and signature integrity verification on the plugin; Upon receiving a loading request for a third-party plugin, the plugin manager first performs a whitelist access verification. The plugin manager reads the built-in whitelist from the engine's read-only code segment. This whitelist contains allowed plugin IDs and / or corresponding version ranges. The plugin manager matches the plugin ID and version to be loaded against the whitelist. If the plugin ID is not in the whitelist, or the version exceeds the allowed range, loading the plugin is directly rejected. After the whitelist access verification passes, the plugin manager performs a signature integrity verification: First, it calculates the hash value (e.g., a blake3 hash value) of the plugin package (containing the plugin manifest, source code, and native code). Then, using the engine's embedded public key (e.g., xos_verify_key), it verifies the digital signature attached to the plugin package using an asymmetric cryptographic algorithm, checking if the hash value matches the signature. If they do not match, the plugin package is deemed tampered with, and loading is rejected.

[0019] In this step, whitelist access verification focuses on "identity verification," determining which plugins are eligible to be loaded and defending against "unknown plugins." Signature integrity verification focuses on "integrity proof," ensuring that the loaded plugin has not been tampered with. The two layers of verification responsibilities are separated, forming a defense-in-depth system. For example, even if an attacker obtains the signing key, if the plugin identifier is not in the whitelist, a malicious plugin cannot be loaded. If an attacker tampers with the engine whitelist (requiring modification of the engine binary file), but cannot forge a legitimate signature, the tampered plugin cannot be loaded. It should be noted that in this embodiment, whitelist access verification is performed before signature verification. In practical applications, signature verification can be performed first, followed by whitelist access verification, or even both can be performed simultaneously. If either verification fails, the plugin will be refused loading.

[0020] Step S12: Perform plugin security level binding and permission verification during JIT compilation; The JIT compiler reads the plugin manifest (plugin-manifest.json) that has passed two-layer verification, extracts the declared permission information, and generates corresponding Plugin Capability Types for each declared permission. For example, if a plugin declares the "net.intercept" permission, it generates the PluginCap_NetIntercept capability type. For permissions not declared by the plugin, no corresponding capability type is generated. Subsequently, the JIT compiler modifies the function signatures of system extension point APIs, automatically adding (implicit) capability type parameters. For example, the signature of the system extension point API "registerOutboundFilter" is modified as follows: plaintext fn registerOutboundFilter( hook: fn(packet: PacketView) -> FilterResult, __cap: PluginCap_NetIntercept / / Implicit capability type parameter void When compiling plugin code, the JIT compiler binds the plugin's security level to Level 1P and automatically inserts SFI (Software Fault Isolation) address mask operations into memory access instructions in the plugin code. One possible specific operation is to convert the memory access address to "plugin base address + (pointer & 0xFFFF_FFFF)", ensuring that the plugin's memory access is restricted to its independent 4GB SFI region. During the capability type checking phase of compilation, the JIT compiler verifies whether the plugin holds a matching capability type flag when calling system extension point APIs. If the plugin attempts to call an API for which no permission is declared (i.e., lacking a matching capability type flag), the plugin code is not compiled, and a compilation error is directly reported. Thus, the compiled output does not contain the instruction sequence for the unauthorized API call, preventing loading. Conversely, if the corresponding capability type flag is present, compilation can proceed smoothly, allowing loading.

[0021] For example, if a plugin does not declare the "fs.write" permission, then the PluginCap_FsWrite capability type does not exist. When the plugin code attempts to call the "fs.writeFile" API, the JIT compiler will detect the lack of the corresponding implicit capability type parameter and directly throw an E4001 compilation error. This unauthorized call instruction sequence will not be compiled into the final binary product, thus structurally eliminating the possibility of unauthorized operations by the plugin.

[0022] Step S13: The plugin manager receives the plugin update request and performs an atomic pointer switch for the plugin hot update; After receiving a plugin update request, the plugin manager first performs double-layer verification in step S11 on the new version plugin. If verification passes, the new version plugin is loaded into a separate SFI area, and step S12 (JIT compilation and initialization) is executed. At this point, the old version plugin continues to run in its original SFI area, with both the old and new versions coexisting in their respective independent SFI areas. The plugin manager uses CAS (Compare-And-Swap) atomic instructions to switch the Hook pointer of the system extension point from the callback function address of the old version plugin to the callback function address of the new version plugin. Simultaneously, it switches the API registration information for the application layer from the old version to the new version.

[0023] During the atomic switch, the plugin manager maintains an atomic `active_call_count` counter for each plugin's SFI region: the counter atomically increments when a new extension point Hook call enters the plugin, and atomically decrements when the Hook call completes and returns. After the atomic switch, the old version plugin's SFI region enters a Shadow state, no longer accepting new Hook calls, and its `active_call_count` counter will only decrement until it reaches 0. The plugin manager waits for the old version SFI region's `active_call_count` counter to reach 0, or waits for a 5-second timeout. If the timeout occurs, it forcibly terminates any remaining coroutines, ensuring that all calls to the old version plugin have completed, and preventing the release of its SFI region before the old call returns.

[0024] In this step, the execution delay of the CAS atomic instruction is approximately 1 ns, achieving zero-interruption switching of the extension point callback. The application layer is unaware of this when calling the plugin API, resolving the service interruption issue associated with hot updates in existing technologies. For example, when a VPN plugin is updated, the network packet filtering Hook function switches via a CAS pointer, ensuring uninterrupted packet filtering service during the switching process and avoiding network connection interruptions.

[0025] Compared with existing Chrome Extensions technology, the technical effects of the technical solution of this application embodiment can be reflected in at least the following three aspects: (1) In terms of security, the instruction sequence of unauthorized API calls is eliminated during compilation. Compared with runtime permission checks, the possibility of unauthorized operations is eliminated from the structure. Even if attackers use memory erosion, JIT spraying and other means, they cannot execute uncompiled unauthorized instructions. The structural security of plugin permission checks is greatly improved; (2) In terms of performance, plugin isolation is achieved by using SFI address mask. Each plugin occupies only 5-15MB of memory. The SFI domain switching delay is about 10ns. Compared with the process isolation of Chrome Extensions (50MB / plugin, IPC delay of 10μs), the memory overhead is reduced by 70%-90%, and the performance overhead is reduced by 99%, which can meet the performance requirements of high-frequency extension points; (3) In terms of continuity, zero-interruption hot update is achieved by CAS atomic pointer switching. There is no service interruption window, which solves the service continuity problem when critical system plugins are updated. Compared with the interruption window of about 100ms in Chrome Extensions, the service availability is improved to 100%.

[0026] Based on the above solution, the embodiments of this application can be optimized in many ways. The following focuses on some important optimization directions.

[0027] One of the optimized technical solutions: automatic rollback during the hot update observation period.

[0028] After the atomic switch in step S13 of the aforementioned technical solution is completed, the plugin manager can start the Watchdog coroutine and enter an observation period of 30 seconds. The Watchdog coroutine monitors the health indicators of the new version plugin, including: the number of plugin crashes (statistics through page error signal SIGSEGV and page failure #PF), the timeout rate of extension point Hook callbacks (the percentage of calls exceeding the preset maximum delay), and the API call error rate.

[0029] During the observation period, if the new version plugin crashes ≥1 time, or the Hook callback timeout rate >10%, or the API error rate exceeds the threshold, an automatic rollback mechanism is triggered: the plugin manager uses CAS atomic instructions to switch the extension point Hook pointer and API registration information from the new version back to the old version, then releases the SFI area of ​​the new version plugin, and the old version plugin recovers from the Shadow state to the Running state. The plugin manager records the audit log of this update failure. If the health indicators of the new version plugin meet the requirements during the observation period, the plugin manager releases the Shadow SFI area of ​​the old version plugin, completing the entire hot update process.

[0030] Compared to existing technologies that lack a rollback mechanism for hot updates, this optimization step, through observation period monitoring and automatic rollback, can quickly restore to a stable old version when a new version plugin malfunctions, avoiding system malfunctions caused by faulty new version plugins. During the observation period, the coexistence of the new and old versions of the SFI area only increases temporary memory overhead by about 10-30MB, and the rollback operation latency is about 1ms, which is far lower than the time required to reload plugins in existing technologies, further improving the security and stability of plugin hot updates.

[0031] Second optimization technical solution: Automatic recovery from plugin crashes.

[0032] When plugin code attempts to access memory out of bounds, it triggers the Guard Pages at the beginning and end of the SFI region, resulting in a #PF (Page Fault). Upon receiving the #PF signal, the engine's page fault handler parses the fault address, locates the plugin's SFI region to which the address belongs, and marks the plugin's status as Crashed.

[0033] After the plugin manager detects that the plugin status is Crashed, it first checks whether the number of restarts of the plugin has not exceeded the maximum number of restarts declared in the plugin list. If it has not exceeded the maximum number of restarts, it performs the following operations: First, it calls the munmap system call function to release the entire SFI region of the plugin. This operation is a resource reclamation with an O(1) time complexity, which only takes about 10μs to release all the memory resources occupied by the plugin. It does not require traversing the GC heap, executing the finalizer, or cleaning up system resources such as file descriptors (because there are no system resource handles in the SFI region). Second, it waits for a cooldown period (such as 1 second) to prevent the plugin from restarting rapidly. Third, it re-executes the double verification, JIT compilation, and initialization operations of the above steps to restore the service of the plugin, increments the number of restarts of the plugin by 1, and records the crash audit log. If the number of restarts of the plugin has reached the maximum number of restarts, the plugin status is marked as Failed, the user is notified, and the administrator is asked to intervene manually.

[0034] The technical benefits of this optimization are as follows: When a Chrome Extensions plugin crashes, the entire plugin process needs to be restarted, which takes about 100ms and requires cleaning up the IPC channel. However, this optimization isolates the plugin through an SFI fault domain, so the plugin crash only affects its own 4GB SFI area and will not affect other plugins or applications. Moreover, resource reclamation and restart take only about 10μs + JIT compilation time, improving crash recovery efficiency by about 1000 times and significantly reducing the impact of plugin crashes on the system.

[0035] The third optimized technical solution: versioned management of extension point APIs.

[0036] The plugin declares the minimum extension point API version (min_extension_api) required in its manifest. After performing the whitelist verification in step S11, the plugin manager further verifies whether the minimum version is not higher than the extension point API version currently provided by the engine: if it is higher, the plugin is rejected from loading; if it is not higher, the loading process is allowed to continue.

[0037] The version evolution of extension point APIs follows backward compatibility rules: when a new extension point is added, the API version undergoes a minor version upgrade (e.g., from 1.0 to 1.1); when the function signature of an existing extension point is modified, the API version undergoes a major version upgrade (e.g., from 1.1 to 2.0); existing extension points cannot be deleted, they can only be marked as deprecated.

[0038] Compared with existing technologies, existing plugin hot-loading technologies lack a unified API version management mechanism, which can easily lead to incompatibility issues between plugins and engine APIs. This step, however, ensures API compatibility during plugin loading through clear API version verification and evolution rules, avoiding plugin loading failures or abnormal operation due to API version mismatches, thereby improving the compatibility and stability of the plugin ecosystem.

[0039] Fourth optimization technical solution: cross-security level inline optimization.

[0040] For plugin extension point callback functions that satisfy the pure function constraint (no side effects, input and output depend only on parameters, and no global state dependency), the engine inlines the callback function into the engine's hot path during JIT compilation, eliminating the overhead of SFI domain switching and reducing the extension point call latency from 10ns to about 2ns.

[0041] The technical effects of this optimization step: In the existing technology, the call to the plugin callback function needs to go through inter-process communication or SFI domain switching, which has fixed overhead; this step further reduces the call latency of high-frequency extension points through inlining optimization, improves the overall system performance, and is especially suitable for low-latency requirements such as per-packet network filtering and high-frequency log collection.

[0042] The foregoing description details the system plug-in hot-loading method provided in the embodiments of this application. In fact, the embodiments of this application also provide an apparatus (system) corresponding to this method. See [link to relevant documentation]. Figure 3 The diagram illustrates the structural block diagram of the system plugin hot-loading system. The hot-loading system U30 includes a plugin manager U31 and a just-in-time compiler U32, wherein: The plugin manager U31 is used to receive loading requests for plugins to be loaded, check whether the plugin identifier and / or the version corresponding to the plugin are in the engine's built-in whitelist, and / or verify the digital signature attached to the plugin using an asymmetric cryptographic algorithm; if it is in the whitelist and / or verified by digital signature, the just-in-time compiler is triggered. The just-in-time compiler U32 is used to generate the corresponding capability type based on the permissions declared in the plugin manifest when compiling the plugin's code; during capability type checking, it verifies whether the plugin calls the extension point API and holds a matching capability type tag. If so, the plugin code is compiled to enable loading.

[0043] The above-described apparatus embodiments can achieve the same technical effects as the aforementioned method embodiments, and can also be optimized in various aspects to form an optimized system with even better technical effects to further solve related problems. To avoid repetition, further details are omitted here. Furthermore, the technical solutions of this application can be formed on a computer-readable storage medium to create a computer program for implementing the various steps of the aforementioned method embodiments.

[0044] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0045] The embodiments of this application can achieve all the inventive objectives using the aforementioned software; therefore, the software portion has been primarily described. Those skilled in the art should understand that the embodiments of this application can be provided as an apparatus, system, or related computer program product. Therefore, this application can be implemented entirely in hardware, entirely in software, or in a combination of software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0046] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0047] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0048] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0049] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent storage in computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media. Computer-readable media includes both permanent and non-persistent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information that can be accessed by the computing device. As defined in this article, computer-readable media do not include transient media, such as modulated data signals and carrier waves.

[0050] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0051] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for hot-loading system plug-ins, characterized in that, The method includes: Receive a loading request for a plugin to be loaded, check whether the plugin's identifier and / or the version corresponding to the plugin are in the engine's built-in whitelist, and / or verify the digital signature attached to the plugin using an asymmetric cryptographic algorithm; if it is in the whitelist and / or verified by digital signature, then perform the following compilation steps; When compiling the plugin code, the corresponding capability type is generated based on the permissions declared in the plugin manifest. During capability type checking, it is verified whether the plugin calls the extension point API and holds a matching capability type tag. If so, the plugin code is compiled to enable loading.

2. The method according to claim 1, characterized in that, The code for the compilation plugin specifically includes: Read the permission declarations in the plugin manifest and generate a corresponding capability type tag for each declared permission; add capability type parameters to the function signature of the system extension point API based on the capability type tags; During capability type checking, verify whether the plugin calls the system extension point API and holds a matching capability type tag. If it does, compile the plugin's code; otherwise, report a compilation error.

3. The method according to claim 1, characterized in that, The method further includes: When compiling the plugin's code, a software fault isolation constraint with a specified security level is imposed on the plugin's code. A software fault isolation region address mask is inserted at the memory access instruction to restrict the plugin's code memory access to the software fault isolation region.

4. The method according to claim 1, characterized in that, The method further includes: During hot updates, the new version of the plugin is loaded into an independent software fault isolation area, and the extension point callback is switched from the old version of the plugin to the new version of the plugin through an atomic pointer switching operation to achieve zero service interruption updates.

5. The method according to claim 4, characterized in that, The hot update also includes an automatic rollback step during the observation period: After switching atomic pointers, the software fault isolation area of ​​the old version of the plugin is retained as a shadow state; Monitor the health metrics of the new version plugin during the observation period, including the number of crashes, extension point callback timeout rate, and / or API error rate; When the health indicator exceeds the preset threshold, the extension point callback is restored to the old version of the plugin by switching atomic pointers, and the software fault isolation area of ​​the new version of the plugin is released.

6. The method according to claim 1, characterized in that, The method also includes a fault recovery step when the plugin crashes, specifically including: When a page error is detected in the protection page of the plug-in software fault isolation area, the plug-in that has the page error is marked as crashed. Release the software fault isolation SFI area of ​​the plugin that caused the page fault; The loading process will be re-executed after the cooldown period to restore the plugin service.

7. The method according to claim 6, characterized in that, The method further includes: Before releasing the software fault isolation region of the plugin that caused the page fault, when a page fault is detected in the protected page of the plugin's software fault isolation region, it is checked whether the number of restarts of the plugin that caused the page fault has exceeded the maximum number of restarts declared in the plugin list; if it has not exceeded the maximum number of restarts, the step of releasing the software fault isolation region of the plugin that caused the page fault is executed.

8. The method according to claim 1, characterized in that, The method also includes an extension point API versioning management step, specifically including: Before executing the compilation step, the plugin manifest declares the minimum extension point API version required; the engine verifies whether the minimum extension point API version required by the plugin declaration is not higher than the currently provided extension point API version. If it is not higher, the compilation step is executed; if it is higher, the compilation step is not executed.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 8.

10. A system plug-in hot-loading system, characterized in that, The hot-loading system includes a plugin manager and a just-in-time compiler, wherein: The plugin manager is used to receive loading requests for plugins to be loaded, check whether the plugin's identifier and / or the version corresponding to the plugin are in the engine's built-in whitelist, and / or verify the digital signature attached to the plugin using an asymmetric cryptographic algorithm; if it is in the whitelist and / or passes the digital signature verification, then the just-in-time compiler is triggered. The just-in-time compiler is used to generate corresponding capability types based on the permissions declared in the plugin manifest when compiling the plugin's code; during capability type checking, it verifies whether the plugin calls the extension point API and holds a matching capability type tag. If so, the plugin's code is compiled to enable loading.

Images