Secure dynamic loading method for peripheral adapter plug-in in embedded low-resource environment

Abstract

The invention relates to a safe dynamic loading method for a peripheral adaptive plug-in in an embedded low-resource environment, and belongs to the technical field of plug-in loading. The method comprises the following steps: executing digital signature identity authentication and lightweight increment integrity verification; analyzing the metadata, and distributing a physical isolation memory area by utilizing a memory management unit; initializing and analyzing the peripheral dependency list in the isolation memory, dynamically generating an encryption capability token bound with an isolation domain identifier, and embedding a monitoring hook to verify the authority of the token; performing lightweight behavior auditing during operation, triggering a response mechanism based on a result, and checking a certificate state by using a pre-downloaded certificate revocation list incremental data packet when the system is idle; verifying the new-version plug-in independently, pausing the old-version capture state snapshot, switching the peripheral control right to the new-version plug-in through the atomic operation sequence, recovering the token and safely erasing the memory. The whole mechanism ensures high-security isolation and dynamic protection. The efficient and safe loading and operation of the peripheral adaptive plug-in under the embedded low-resource environment are realized.

Description

Technical Field

[0001] This invention belongs to the field of plug-in loading technology, specifically relating to a secure dynamic loading method for peripheral adapter plug-ins in embedded low-resource environments. Background Technology

[0002] Modern embedded devices (such as IoT terminals and industrial controllers) require dynamic access to diverse peripherals, giving rise to modular plug-in architectures. Plug-ins are typically developed by third parties and achieve plug-and-play functionality by dynamically loading peripherals. These devices generally use Cortex-M level microcontrollers, which have strictly limited resources (RAM / KB level, Flash / MB level), making it impossible to deploy a complete TEE or hypervisor.

[0003] Static signature verification only verifies integrity at load time and cannot defend against runtime memory tampering. Traditional MPU / MMU configurations cannot simultaneously guarantee execution / storage isolation of code and data. Plugins may gain unauthorized access to peripherals or system resources. Hot update processes are prone to causing state inconsistencies or peripheral control interruptions.

[0004] The main technical problems at present focus on: (1) Security flaws in the dynamic loading process: Full hash verification consumes significant CPU resources, failing to meet the real-time requirements of low-power devices. The lack of separation between code and data areas allows attackers to inject malicious code through the data area. Direct CPU access to plugin file images may allow them to be stolen or tampered with by the hardware debugging interface.

[0005] (2) Weak security protection during operation: The plugin can arbitrarily access sensitive peripherals, lacking a mechanism for granting least privileges. Traditional solutions rely on static rules, which cannot detect peripheral operation sequences with abnormal timing. Offline devices cannot obtain CRLs in a timely manner, allowing plugins with revoked certificates to still run.

[0006] (3) Security risks of hot updates and uninstallation: Directly switching memory domains may result in the loss of peripheral register states. Simple memory releases that do not erase sensitive data can be recovered through cold boot attacks. Non-atomic update processes are easily interrupted, leading to an inconsistent "half-old, half-new" state for the system.

[0007] (4) Performance bottlenecks in low-resource scenarios: DFA matching requires a large amount of RAM (state table storage), and coprocessor operations increase power consumption. Typical CRL sizes exceed 100KB, making them unsuitable for resource-constrained devices. The Secure Element chip exhibits high latency, and frequent read / write operations reduce system responsiveness. Summary of the Invention

[0008] To address the aforementioned problems in the existing technology, this invention provides a secure dynamic loading method for peripheral adapter plugins in embedded low-resource environments. The objective of this invention can be achieved through the following technical solutions: A secure dynamic loading method for peripheral adapter plugins in embedded low-resource environments includes: S1: Before the plugin is loaded into the execution environment, perform digital signature-based identity authentication and lightweight incremental integrity verification in sequence; S2: Parse the type identifier in the plugin metadata. Under the control of the operating system kernel, use the memory management unit to allocate a physically isolated protected memory area. Divide the protected memory area into a non-executable data storage area and an executable code area. Through a controlled direct memory access channel, load the verified plugin code segment and data segment into the code area and data area respectively, and block the central processing unit's direct access path to the plugin's original file image. S3: Execute the plugin's initialization function in an isolated memory environment, restricting memory access to its own isolation domain; parse the peripheral dependency list declared by the plugin, dynamically generating an encrypted capability token bound to a unique identifier of the current memory isolation domain; embed monitoring hook functions at the plugin's peripheral access interface, forcibly verifying the validity and permission scope of the current capability token each time an access request is initiated; allocate preset CPU time slices, stack depths, and interrupt response frequency limits for the plugin initialization process; S4: Lightweight runtime behavior auditing is continuously performed during plugin operation, and an adaptive violation response mechanism is triggered based on the audit results. By utilizing system idle periods, the current validity status of the plugin certificate is checked using pre-downloaded certificate revocation list incremental data packets. S5: Independently execute the S1-S3 process for the new version plugin; when the new version plugin passes verification, pause the old version plugin and capture its key runtime state to form a state snapshot; seamlessly switch the control of the target peripheral and the state snapshot to the memory isolation domain of the new version plugin through an atomic operation sequence; reclaim all capability tokens granted to the plugin and perform secure data erasure on the isolated memory area occupied by the plugin.

[0009] Specifically, the identity authentication based on digital signature in S1 is as follows: based on the elliptic curve digital signature algorithm, the developer's public key pre-installed in the device's secure storage area is used to verify the digital signature attached to the plugin.

[0010] Specifically, the lightweight incremental integrity check in S1 is as follows: using an optimized differential hash algorithm, the feature hash value of the region in the key code segment of the plugin with a modification probability exceeding a preset threshold is selectively calculated and compared with the baseline hash value pre-stored in the secure storage area.

[0011] Specifically, the lightweight behavior audit in S4 includes: capturing peripheral access behavior events of the plugin through embedded monitoring hook functions, inputting them into the rule engine in real time, and matching them with a predefined set of abnormal operation patterns.

[0012] Specifically, the adaptive violation response in S4 includes: Static response: Based on the predefined violation types and their associated preset severity levels matched by the rule engine, execute the corresponding control policies; Dynamic response: Real-time acquisition of peripheral access behavior data streams captured by monitoring hook functions, extraction of multi-dimensional behavior feature vectors, and calculation of real-time risk scores; dynamic determination of violation level based on the real-time risk scores, and execution of control measures of corresponding intensity; The multi-dimensional behavioral feature vector includes operation frequency, data throughput deviation, and sensitive instruction call sequence.

[0013] Specifically, in S5, the peripheral control and state snapshot are switched to the new plugin memory domain through atomic operations, including: S501: Pauses the clock signals of all target peripheral buses via the peripheral controller and freezes their register states. The frozen register state values ​​are then encrypted and stored in the protected memory area of ​​a security chip that meets FIPS 140-2 Level 3 physical tamper-proof requirements. This memory area is only accessible to legitimate instructions verified by the elliptic curve digital signature algorithm. S502: Executes a sequence of atomic operations using the page table / region mapping mechanism of the memory management unit: Mark the page table entries / region descriptors of the old plugin memory isolation domain as read-only; copy the physical memory pages / data blocks that need to be migrated from the old domain to the new plugin memory isolation domain; perform cyclic redundancy check on the memory copies in the new domain; after the check passes, remove the mapping relationship of the page table entries / region descriptors of the old domain; configure the page table entries / region descriptors corresponding to the new domain to executable and read-write states. S503: Decrypts and restores peripheral register state from protected memory area of ​​security chip; remaps base address of peripheral controller register space to memory isolation domain of new plug-in; restores peripheral bus clock signal and inserts random delay in the first clock cycle to resist timing bypass attack; S504: During unloading, data is erased in the isolated memory area using a 7-round overwrite operation based on the DoD 5220.22-M ECE standard; the plug-in image itself and its redundant backups stored in flash memory must be thoroughly cleared through physical addressing.

[0014] Specifically, the specific implementation methods for saving runtime state snapshots as described in S5 include: Only capture the volatile runtime state of legacy plugins, including: stack pointer, program counter, and kernel register values; address ranges and checksums of dynamically allocated heap memory blocks marked as dirty data. Encoding of the current stage of the peripheral interaction state machine; State data is compressed using the lightweight LZ4-HC algorithm; The compressed state snapshot is divided into multiple data blocks, which are then encrypted using different session keys generated by the security chip hardware key derivation function. Each encrypted block is appended with a region integrity check code generated based on the memory protection unit mechanism. The encrypted blocks are then distributed and stored in the reserved area of ​​the new plugin's memory isolation domain and the tamper-proof storage area of ​​the security chip. When the new domain is restored, the data blocks are combined and decrypted to verify the integrity of the memory protection unit checksum; pre-write verification is performed on the restored dirty data blocks in the heap memory, and the restored checksum is compared with the current value of the target address; if the difference exceeds the preset threshold, the preset security rollback mechanism is triggered. During the plugin initialization phase, its heap memory region is configured to write-protected mode through the memory protection unit. When the plugin first attempts to write to this region, a page fault / memory protection fault interrupt is triggered. The monitoring program records the write address range and marks it as a dirty block. Then, the write protection is temporarily lifted to allow writing.

[0015] Specifically, the processing method for the pre-downloaded certificate revocation list incremental data packet described in S4 includes: During device startup, a lightweight Bloom filter data package containing a set of hashes of revoked certificate IDs is downloaded from a cloud security server. When verifying the plug-in certificate: extract the certificate serial number and calculate its double hash value; query the Bloom filter data packet, and if it returns "may exist", trigger a full CRL comparison; the full CRL comparison adopts a binary search segmented by timestamp, with a maximum search depth of 5 layers; the false positive rate of the Bloom filter is preset and stored in the one-time programmable storage area of ​​the security chip.

[0016] Specifically, the storage and verification method of the encryption capability token in S3 includes: The plaintext token is dynamically generated or decrypted by the security chip only when verification is required, and is destroyed immediately after verification; the encrypted form of the token or its secure handle can be stored in the protected configuration register of the memory protection unit / memory management unit or the kernel's security context storage area; When the device resumes from hibernation, it is encrypted using the physical non-clonable function derived key of the security chip and stored in Flash, and each token is bound to the configuration hash value of the current memory isolation domain. In the monitoring hook function, a hardware-assisted comparator is used to match the domain hash value bound in the token with the real-time hash output value of the current active memory isolation domain configuration register.

[0017] Specifically, the rule engine implementation for lightweight behavior auditing described in S4 is as follows: The hardware acceleration layer inputs peripheral access behavior data streams to the programmable state machine via DMA; the programmable state machine matches atomic rules in real time. The coprocessor layer performs complex rule matching on the event stream output by the programmable state machine; the coprocessor layer uses a pre-compiled deterministic finite automaton model for efficient matching. The dynamic learning layer calculates the risk probability of events reported by the coprocessing layer based on a lightweight Bayesian network, automatically generates new rules, signs them, and stores them in the rule base of the programmable state machine; the rule base update needs to go through the signature verification process of S1.

[0018] The beneficial effects of the present invention are: The method of this invention effectively improves the security of peripheral adapter plugin loading and operation in embedded low-resource environments through a multi-stage security verification and protection mechanism. During the plugin loading stage, digital signature-based authentication and lightweight incremental integrity verification ensure the legitimacy of the plugin's origin and the integrity of the code, preventing intrusion by malicious plugins. Lightweight incremental integrity verification only calculates areas with a high probability of modification in critical code segments, reducing computational load and making it suitable for low-resource environments.

[0019] Memory isolation mechanisms and cryptographic tokens further enhance the security of plugin operation. Memory isolation ensures that plugins can only access their own isolated domains, preventing interference and data leakage between different plugins. Cryptographic tokens strictly control peripheral access permissions for plugins, allowing only verified access requests and preventing unauthorized access.

[0020] Lightweight behavior auditing and adaptive violation response mechanisms can monitor plugin behavior in real time, promptly detecting and handling abnormal operations. By utilizing system idle periods to verify the validity of plugin certificates, the legitimacy of plugins during operation is ensured.

[0021] When plugin versions are updated, the system ensures continuity and stability by capturing snapshots of the old plugin's runtime state and seamlessly switching to the new version. Simultaneously, it performs secure data erasure of memory areas occupied by the old plugin to prevent security risks arising from data residue.

[0022] In summary, this invention ensures the safe loading and operation of the plugin while fully considering the characteristics of embedded low-resource environments. By optimizing the algorithm and making reasonable use of system resources, it achieves a balance between security and performance, and has high practical value and promotional significance. Attached Figure Description

[0023] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0024] Figure 1 This is a flowchart illustrating a secure dynamic loading method for peripheral adapter plugins in an embedded low-resource environment according to the present invention. Figure 2 This is a schematic diagram of memory isolation domain partitioning and DMA channel configuration in this invention; Figure 3 This is a diagram illustrating the architecture of the capability token generation and verification mechanism in this invention. Figure 4 A schematic diagram of the implementation scheme for a behavior audit rules engine; Figure 5 Flowchart for switching peripheral control in atomic operation sequences; Figure 6 This is a diagram illustrating the state snapshot saving and restoration mechanism; Figure 7 A diagram illustrating the configuration and write protection mechanism for the memory protection unit. Detailed Implementation

[0025] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0026] Please see Figure 1-7 A secure dynamic loading method for peripheral adapter plugins in embedded low-resource environments, comprising: S1: Before the plugin is loaded into the execution environment, perform digital signature-based identity authentication and lightweight incremental integrity verification in sequence; S2: Parse the type identifier in the plugin metadata. Under the control of the operating system kernel, use the memory management unit to allocate a physically isolated protected memory area. Divide the protected memory area into a non-executable data storage area and an executable code area. Through a controlled direct memory access channel, load the verified plugin code segment and data segment into the code area and data area respectively, and block the central processing unit's direct access path to the plugin's original file image. S3: Execute the plugin's initialization function in an isolated memory environment, restricting memory access to its own isolation domain; parse the peripheral dependency list declared by the plugin, dynamically generating an encrypted capability token bound to a unique identifier of the current memory isolation domain; embed monitoring hook functions at the plugin's peripheral access interface, forcibly verifying the validity and permission scope of the current capability token each time an access request is initiated; allocate preset CPU time slices, stack depths, and interrupt response frequency limits for the plugin initialization process; S4: Lightweight runtime behavior auditing is continuously performed during plugin operation, and an adaptive violation response mechanism is triggered based on the audit results. By utilizing system idle periods, the current validity status of the plugin certificate is checked using pre-downloaded certificate revocation list incremental data packets. S5: Independently execute the S1-S3 process for the new version plugin; when the new version plugin passes verification, pause the old version plugin and capture its key runtime state to form a state snapshot; seamlessly switch the control of the target peripheral and the state snapshot to the memory isolation domain of the new version plugin through an atomic operation sequence; reclaim all capability tokens granted to the plugin and perform secure data erasure on the isolated memory area occupied by the plugin.

[0027] Specifically, the identity authentication based on digital signature in S1 is as follows: based on the elliptic curve digital signature algorithm, the developer's public key pre-installed in the device's secure storage area is used to verify the digital signature attached to the plugin.

[0028] Specifically, the lightweight incremental integrity check in S1 is as follows: using an optimized differential hash algorithm, the feature hash value of the region in the key code segment of the plugin with a modification probability exceeding a preset threshold is selectively calculated and compared with the baseline hash value pre-stored in the secure storage area.

[0029] In this embodiment, the differential hash algorithm for lightweight incremental integrity verification only calculates regions (dynamic link table, interrupt vector table) in the code segment with a modification probability > 30%. A pseudocode example is shown below: { / / Pseudocode example for (section in plugin.sections){ if (section.modify_probability>threshold){ hash = optimized_delta_hash(section.data); / / Only calculate the grayscale difference between lines. if (hash != pre_stored_hash) trigger_alert(); } }} Specifically, the lightweight behavior audit in S4 includes: capturing peripheral access behavior events of the plugin through embedded monitoring hook functions, inputting them into the rule engine in real time, and matching them with a predefined set of abnormal operation patterns.

[0030] Specifically, the adaptive violation response in S4 includes: Static response: Based on the predefined violation types and their associated preset severity levels matched by the rule engine, execute the corresponding control policies; Dynamic response: Real-time acquisition of peripheral access behavior data streams captured by monitoring hook functions, extraction of multi-dimensional behavior feature vectors, and calculation of real-time risk scores; dynamic determination of violation level based on the real-time risk scores, and execution of control measures of corresponding intensity; The multi-dimensional behavioral feature vector includes operation frequency, data throughput deviation, and sensitive instruction call sequence.

[0031] Specifically, in S5, the peripheral control and state snapshot are switched to the new plugin memory domain through atomic operations, including: S501: Pauses the clock signals of all target peripheral buses via the peripheral controller and freezes their register states. The frozen register state values ​​are then encrypted and stored in the protected memory area of ​​a security chip that meets FIPS 140-2 Level 3 physical tamper-proof requirements. This memory area is only accessible to legitimate instructions verified by the elliptic curve digital signature algorithm. S502: Executes a sequence of atomic operations using the page table / region mapping mechanism of the memory management unit: Mark the page table entries / region descriptors of the old plugin memory isolation domain as read-only; copy the physical memory pages / data blocks that need to be migrated from the old domain to the new plugin memory isolation domain; perform cyclic redundancy check on the memory copies in the new domain; after the check passes, remove the mapping relationship of the page table entries / region descriptors of the old domain; configure the page table entries / region descriptors corresponding to the new domain to executable and read-write states. S503: Decrypts and restores peripheral register state from protected memory area of ​​security chip; remaps base address of peripheral controller register space to memory isolation domain of new plug-in; restores peripheral bus clock signal and inserts random delay in the first clock cycle to resist timing bypass attack; S504: During unloading, data is erased in the isolated memory area using a 7-round overwrite operation based on the DoD 5220.22-M ECE standard; the plug-in image itself and its redundant backups stored in flash memory must be thoroughly cleared through physical addressing.

[0032] In this embodiment, the schematic diagram of memory isolation domain partitioning and DMA channel configuration is as follows: Figure 2As shown, the operating system kernel allocates non-contiguous physical memory blocks through the MMU, and each plugin has its own isolated domain. The code segment has the XN (Execute-Never) bit set, execution permissions are disabled in the data segment, and the ARM MPU is configured with 8 protected regions. The domain boundary registers are stored in the security chip (Claim10). The tamper-proof design enables a memory encryption engine (Intel SGX), and the data segment uses AES-GCM encryption, with the key dynamically derived from the security chip.

[0033] In this embodiment, as Figure 3 As shown, the security chip receives the peripheral dependency list and isolation domain ID, generates a capability token using elliptic curve cryptography, and stores the token in encrypted form in the MPU / MMU register or kernel security area. During hibernation, it is stored using a PUF key for encrypted storage. Access requests trigger monitoring hooks, and the hardware comparator verifies in real time the consistency between the domain ID bound to the token and the currently active domain.

[0034] Specifically, the specific implementation methods for saving runtime state snapshots as described in S5 include: Only capture the volatile runtime state of legacy plugins, including: stack pointer, program counter, and kernel register values; address ranges and checksums of dynamically allocated heap memory blocks marked as dirty data. Encoding of the current stage of the peripheral interaction state machine; State data is compressed using the lightweight LZ4-HC algorithm; The compressed state snapshot is divided into multiple data blocks, which are then encrypted using different session keys generated by the security chip hardware key derivation function. Each encrypted block is appended with a region integrity check code generated based on the memory protection unit mechanism. The encrypted blocks are then distributed and stored in the reserved area of ​​the new plugin's memory isolation domain and the tamper-proof storage area of ​​the security chip. When the new domain is restored, the data blocks are combined and decrypted to verify the integrity of the memory protection unit checksum; pre-write verification is performed on the restored dirty data blocks in the heap memory, and the restored checksum is compared with the current value of the target address; if the difference exceeds the preset threshold, the preset security rollback mechanism is triggered. During the plugin initialization phase, its heap memory region is configured to write-protected mode through the memory protection unit. When the plugin first attempts to write to this region, a page fault / memory protection fault interrupt is triggered. The monitoring program records the write address range and marks it as a dirty block. Then, the write protection is temporarily lifted to allow writing.

[0035] Specifically, the processing method for the pre-downloaded certificate revocation list incremental data packet described in S4 includes: During device startup, a lightweight Bloom filter data package containing a set of hashes of revoked certificate IDs is downloaded from a cloud security server. When verifying the plug-in certificate: extract the certificate serial number and calculate its double hash value; query the Bloom filter data packet, and if it returns "may exist", trigger a full CRL comparison; the full CRL comparison adopts a binary search segmented by timestamp, with a maximum search depth of 5 layers; the false positive rate of the Bloom filter is preset and stored in the one-time programmable storage area of ​​the security chip.

[0036] Specifically, the storage and verification method of the encryption capability token in S3 includes: The plaintext token is dynamically generated or decrypted by the security chip only when verification is required, and is destroyed immediately after verification; the encrypted form of the token or its secure handle can be stored in the protected configuration register of the memory protection unit / memory management unit or the kernel's security context storage area; When the device resumes from hibernation, it is encrypted using the physical non-clonable function derived key of the security chip and stored in Flash, and each token is bound to the configuration hash value of the current memory isolation domain. In the monitoring hook function, a hardware-assisted comparator is used to match the domain hash value bound in the token with the real-time hash output value of the current active memory isolation domain configuration register.

[0037] Specifically, the rule engine implementation for lightweight behavior auditing described in S4 is as follows: The hardware acceleration layer inputs peripheral access behavior data streams to the programmable state machine via DMA; the programmable state machine matches atomic rules in real time. The coprocessor layer performs complex rule matching on the event stream output by the programmable state machine; the coprocessor layer uses a pre-compiled deterministic finite automaton model for efficient matching. The dynamic learning layer calculates the risk probability of events reported by the coprocessing layer based on a lightweight Bayesian network, automatically generates new rules, signs them, and stores them in the rule base of the programmable state machine; the rule base update needs to go through the signature verification process of S1.

[0038] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A secure dynamic loading method for peripheral adapter plugins in embedded low-resource environments, characterized in that, include: S1: Before the plugin is loaded into the execution environment, perform digital signature-based identity authentication and lightweight incremental integrity verification in sequence; S2: Parse the type identifier in the plugin metadata, and under the control of the operating system kernel, use the memory management unit to allocate a physically isolated protected memory area, and divide the protected memory area into a non-executable data storage area and an executable code area. The verified plugin code segment and data segment are loaded into the code area and data area respectively through a controlled direct memory access channel, and the direct access path of the central processing unit to the plugin's original file image is blocked. S3: Execute the plugin's initialization function in an isolated memory environment, restricting memory access to its own isolation domain; parse the peripheral dependency list declared by the plugin, and dynamically generate a cryptographic token bound to a unique identifier of the current memory isolation domain; Embed a monitoring hook function at the plugin's access interface to the peripheral device to force verification of the validity and permission scope of the current capability token each time an access request is initiated; Allocate preset CPU time slices, stack depths, and interrupt response frequency limits for the plugin initialization process; S4: Lightweight runtime behavior auditing is continuously performed during plugin operation, and an adaptive violation response mechanism is triggered based on the audit results. By utilizing system idle periods, the current validity status of the plugin certificate is checked using pre-downloaded certificate revocation list incremental data packets. S5: Independently execute the S1-S3 process for the new version plugin; when the new version plugin passes verification, pause the old version plugin and capture its key runtime state to form a state snapshot; seamlessly switch the control of the target peripheral and the state snapshot to the memory isolation domain of the new version plugin through an atomic operation sequence; reclaim all capability tokens granted to the plugin and perform secure data erasure on the isolated memory area occupied by the plugin.

2. The method according to claim 1, characterized in that, The digital signature-based authentication in S1 specifically involves: using the developer's public key pre-installed in the device's secure storage area, based on the elliptic curve digital signature algorithm, to verify the digital signature attached to the plugin.

3. The method according to claim 1, characterized in that, The lightweight incremental integrity check in S1 specifically involves: using an optimized differential hash algorithm to selectively calculate the feature hash value of regions in the critical code segment of the plugin whose modification probability exceeds a preset threshold, and comparing it with the baseline hash value pre-stored in the secure storage area.

4. The method according to claim 1, characterized in that, The lightweight behavior auditing in S4 specifically includes: capturing peripheral access behavior events of the plugin through embedded monitoring hook functions, inputting them into the rule engine in real time, and matching them with a predefined set of abnormal operation patterns.

5. The method according to claim 1, characterized in that, The adaptive violation response in S4 specifically includes: Static response: Based on the predefined violation types and their associated preset severity levels matched by the rule engine, execute the corresponding control policies; Dynamic response: Real-time acquisition of peripheral access behavior data streams captured by monitoring hook functions, extraction of multi-dimensional behavior feature vectors, and calculation of real-time risk scores; dynamic determination of violation level based on the real-time risk scores, and execution of control measures of corresponding intensity; The multi-dimensional behavioral feature vector includes operation frequency, data throughput deviation, and sensitive instruction call sequence.

6. The method according to claim 1, characterized in that, In S5, the peripheral control and state snapshot are switched to the new plugin memory domain through atomic operations, specifically including: S501: Pauses the clock signals of all target peripheral buses via the peripheral controller and freezes their register states. The frozen register state values ​​are then encrypted and stored in the protected memory area of ​​a security chip that meets FIPS 140-2 Level 3 physical tamper-proof requirements. This memory area is only accessible to legitimate instructions verified by the elliptic curve digital signature algorithm. S502: Executes a sequence of atomic operations using the page table / region mapping mechanism of the memory management unit: Mark the page table entries / region descriptors of the old plugin memory isolation domain as read-only; copy the physical memory pages / data blocks that need to be migrated from the old domain to the new plugin memory isolation domain; perform cyclic redundancy check on the memory copies in the new domain; after the check passes, remove the mapping relationship of the page table entries / region descriptors of the old domain; configure the page table entries / region descriptors corresponding to the new domain to executable and read-write states. S503: Decrypts and restores peripheral register state from protected memory area of ​​security chip; remaps base address of peripheral controller register space to memory isolation domain of new plug-in; restores peripheral bus clock signal and inserts random delay in the first clock cycle to resist timing bypass attack; S504: During unloading, data is erased in the isolated memory area using a 7-round overwrite operation based on the DoD 5220.22-M ECE standard; the plug-in image itself and its redundant backups stored in flash memory must be thoroughly cleared through physical addressing.

7. The method according to claim 1, characterized in that, The specific implementation methods for saving runtime state snapshots as described in S5 include: Only capture the volatile runtime state of legacy plugins, including: stack pointer, program counter, and kernel register values; address ranges and checksums of dynamically allocated heap memory blocks marked as dirty data. Encoding of the current stage of the peripheral interaction state machine; State data is compressed using the lightweight LZ4-HC algorithm; The compressed state snapshot is divided into multiple data blocks, which are then encrypted using different session keys generated by the security chip hardware key derivation function. Each encrypted block is appended with a region integrity check code generated based on the memory protection unit mechanism. The encrypted blocks are then distributed and stored in the reserved area of ​​the new plugin's memory isolation domain and the tamper-proof storage area of ​​the security chip. When the new domain is restored, the data blocks are combined and decrypted to verify the integrity of the memory protection unit checksum; pre-write verification is performed on the restored dirty data blocks in the heap memory, and the restored checksum is compared with the current value of the target address; if the difference exceeds the preset threshold, the preset security rollback mechanism is triggered. During the plugin initialization phase, its heap memory region is configured to write-protected mode through the memory protection unit. When the plugin first attempts to write to this region, a page fault / memory protection fault interrupt is triggered. The monitoring program records the write address range and marks it as a dirty block. Then, the write protection is temporarily lifted to allow writing.

8. The method according to claim 1, characterized in that, The method for processing the pre-downloaded certificate revocation list incremental data packet as described in S4 includes: During device startup, a lightweight Bloom filter data package containing a set of hashes of revoked certificate IDs is downloaded from a cloud security server. When verifying the plug-in certificate: extract the certificate serial number and calculate its double hash value; query the Bloom filter data packet, and if it returns "may exist", trigger a full CRL comparison; the full CRL comparison adopts a binary search segmented by timestamp, with a maximum search depth of 5 layers; the false positive rate of the Bloom filter is preset and stored in the one-time programmable storage area of ​​the security chip.

9. The method according to claim 1, characterized in that, The storage and verification methods for the encryption capability token in S3 specifically include: The plaintext token is dynamically generated or decrypted by the security chip only when verification is required, and is destroyed immediately after verification; the encrypted form of the token or its secure handle can be stored in the protected configuration register of the memory protection unit / memory management unit or the kernel's security context storage area; When the device resumes from hibernation, it is encrypted using the physical non-clonable function derived key of the security chip and stored in Flash, and each token is bound to the configuration hash value of the current memory isolation domain. In the monitoring hook function, a hardware-assisted comparator is used to match the domain hash value bound in the token with the real-time hash output value of the current active memory isolation domain configuration register.

10. The method according to claim 1, characterized in that, The lightweight behavior auditing rule engine implementation method described in S4 is as follows: The hardware acceleration layer inputs peripheral access behavior data streams to the programmable state machine via DMA; the programmable state machine matches atomic rules in real time. The coprocessor layer performs complex rule matching on the event stream output by the programmable state machine; the coprocessor layer uses a pre-compiled deterministic finite automaton model for efficient matching. The dynamic learning layer calculates the risk probability of events reported by the coprocessing layer based on a lightweight Bayesian network, automatically generates new rules, signs them, and stores them in the rule base of the programmable state machine; the rule base update needs to go through the signature verification process of S1.

Images