BIOS (Basic Input / Output System) safety protection and recovery optimization method and system based on event driving

Abstract

The invention discloses a BIOS (Basic Input / Output System) safety protection and recovery optimization method and system based on event driving, and the method comprises the steps: dividing a BIOS into a plurality of modules according to a logic function, and establishing a dependency chain of each module according to a logic relationship among the modules, the dependency chain comprising a dependency relationship between the module and other modules; configuring feature parameters for each module, wherein the feature parameters comprise a module ID, version information and a dependency relationship; monitoring a request event for driving the BIOS to work or change, wherein the request event comprises a target characteristic parameter containing a target module ID, target version information and a target dependency relationship; if the target feature parameter cannot be matched with each feature parameter, determining whether there is a module ID matched with the target module ID, and if there is a module ID matched with the target module ID, determining that the module with the module ID consistent with the target ID is a target module; and driving the target module to change and update the characteristic parameters based on the request event. The system can be efficiently updated, and the safety of the system can be improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an event-driven BIOS security protection and recovery optimization method and system. Background Art

[0002] Computer system security is one of the important research directions in the field of modern information technology. As the first software to run during the computer system startup process, the security of BIOS (Basic Input / Output System) directly affects the security of the entire system. BIOS protection technology is designed to prevent unauthorized access and malicious modification, and ensure the integrity and reliability of system startup and operation. In addition, data recovery technology is also an important part of the computer system security field. It can quickly restore the system or data to normal status when the system fails or the data is damaged.

[0003] Existing BIOS protection technologies mainly include password protection, hardware binding and digital signature. Password protection is the most traditional protection method, which limits access to BIOS by setting a password. Hardware binding uses specific hardware devices to identify legitimate users, thereby protecting the security of BIOS. Digital signature technology ensures the integrity and authenticity of the file by digitally signing the BIOS file.

[0004] Although the existing BIOS protection technology has improved the security of the system to a certain extent, there are still some problems and shortcomings. First, the password protection and hardware binding methods are vulnerable to attacks, such as brute force cracking and side-channel attacks. Second, although digital signature technology can effectively prevent malicious modifications, its computational complexity is relatively high. In addition, when the existing BIOS protection system detects data anomalies, it often lacks an efficient recovery mechanism, resulting in a long system recovery time, affecting the availability and reliability of the system.

[0005] The disclosure of the above background technology content is only used to assist in understanding the inventive concept and technical solution of the present invention. It does not necessarily belong to the prior art of the present application, nor does it necessarily provide technical guidance. In the absence of clear evidence that the above content has been disclosed before the filing date of the present application, the above background technology should not be used to evaluate the novelty and creativity of the present application. Summary of the invention

[0006] The purpose of the present invention is to provide an event-driven BIOS security protection and recovery optimization method and system, which can efficiently update the system and improve the security of the system.

[0007] To achieve the above object, the technical solution adopted by the present invention is as follows: A BIOS security protection and recovery optimization method based on event-driven includes the following steps: Divide the BIOS into multiple modules according to logical functions, and establish a dependency chain of each module according to the logical relationship between each module, wherein the dependency chain includes the dependency relationship between the module and other modules; Configuring corresponding characteristic parameters for each module, wherein the characteristic parameters include module ID, version information and the dependency relationship; Monitoring a request event that drives the BIOS to work or change, wherein the request event includes a target characteristic parameter, and the target characteristic parameter includes a target module ID, a target version information, and a target dependency relationship; If the target characteristic parameter and each of the characteristic parameters cannot match each other, determine whether there is a module ID that matches the target module ID. If so, determine that the module corresponding to the module ID that matches the target ID is the target module; The target module is driven to change based on the request event, and the characteristic parameters of the target module are updated to target characteristic parameters accordingly.

[0008] Furthermore, any one of the above-mentioned technical solutions or a combination of multiple technical solutions further includes the following steps: If the target characteristic parameter cannot match each of the characteristic parameters, and there is no module ID that matches the target module ID, determine whether the type of the request event is a newly added module. If so, perform a security check on the request event. If the check passes, add a corresponding functional module based on the request event. If the type of the request event is not a new module, or the security check of the request event fails, the request event is ignored.

[0009] Furthermore, any one of the above-mentioned technical solutions or a combination of multiple technical solutions further includes the following steps: If the target characteristic parameter cannot match any of the characteristic parameters, and there is no module ID that matches the target module ID, the request event is ignored.

[0010] Furthermore, any one of the above-mentioned technical solutions or a combination of multiple technical solutions further includes the following steps: If the target characteristic parameter matches the characteristic parameter, the matching module is driven to operate according to the request event.

[0011] Furthermore, any one of the above-mentioned technical solutions or a combination of multiple technical solutions further includes the following steps: During the operation of the BIOS, a logical snapshot corresponding to each module is generated periodically, wherein the logical snapshot includes characteristic parameters and operation status, and the operation status includes normal operation and abnormal operation; When the module is tampered with or has an abnormality, the module recovery mechanism is triggered, including: Determining through the logical snapshot that the module version whose running status is normal is a trusted version; The current version of the module is replaced with the trusted version, and characteristic parameters of the module are updated accordingly.

[0012] Further, based on any one of the above-mentioned technical solutions or a combination of multiple technical solutions, replacing the current version of the module with the trusted version includes: Determining abnormal data in the current version of the module by comparing the current version of the module with the trusted version; The abnormal data is overwritten with the corresponding data in the trusted version.

[0013] Furthermore, any one of the above-mentioned technical solutions or a combination of multiple technical solutions further includes the following steps: During the operation of the BIOS, a logical snapshot corresponding to each module is generated periodically, wherein the logical snapshot includes characteristic parameters and operation status, and the operation status includes normal operation and abnormal operation; Determining through the previous logical snapshot that the module version whose running status is normal is a trusted version; For each module, after generating the latest logical snapshot, the latest logical snapshot is compared with the logical snapshot corresponding to the most recent trusted version. If the comparison is consistent, the current module is determined to be normal, otherwise the current module is determined to be an untrusted module.

[0014] Furthermore, any one of the above-mentioned technical solutions or a combination of multiple technical solutions further includes the following steps: For the untrusted module, a security check is performed on the module. If the check passes, it is determined that the untrusted module is normal and the untrusted module is not changed; otherwise, it is determined that the untrusted module is abnormal, and the current version of the untrusted module is replaced by the trusted version, and the characteristic parameters of the untrusted module are updated accordingly.

[0015] Further, based on any one of the above-mentioned technical solutions or a combination of multiple technical solutions, a logical snapshot corresponding to the module is regularly generated in the following manner: Creating an initial logic snapshot corresponding to the module of the initial version, wherein the initial logic snapshot includes the characteristic parameters, the running status and the core code; An incremental logic snapshot method is used to periodically generate logic snapshots corresponding to the module, including recording the parts that have changed compared to the previous version of the logic snapshot, including the changed characteristic parameters, operating status and code.

[0016] Further, based on any one of the technical solutions or a combination of multiple technical solutions described above, the logical snapshot is configured to be stored in the NVRAM area of ​​the BIOS, and when the module recovery mechanism is triggered, the trusted version corresponding to the module to be restored is loaded from the NVRAM area, and the current version of the module is overwritten by the trusted version.

[0017] Further, based on any one of the above technical solutions or a combination of multiple technical solutions, the module includes a hardware initialization module, a device driver module and a monitoring module, wherein the dependency relationship of the device driver module is that it depends on the hardware initialization module to be executed first, and the dependency relationship of the monitoring module is that it depends on the device driver module to be executed first; The monitoring module is configured to monitor the operating status and changes of other modules to generate a logical snapshot corresponding to the module, wherein the logical snapshot includes characteristic parameters and operating status.

[0018] According to another aspect of the present invention, the present application provides a BIOS system, which is configured to perform security protection and exception recovery using an event-driven BIOS security protection and recovery optimization method as described in any one of the above technical solutions or any combination of multiple technical solutions.

[0019] According to another aspect of the present invention, the present application provides a computer system, which includes a BIOS system as described in any one of the above technical solutions or any one of the combinations of multiple technical solutions.

[0020] The beneficial effects brought by the technical solution provided by the present invention are as follows: a. The present invention compares and matches the target characteristic parameters corresponding to the request event with the characteristic parameters corresponding to each module, determines that the request event is an event that drives the corresponding module to change according to the result that they cannot match consistently, and accurately locates the target module that needs to be changed based on the comparison result of the characteristic parameters, triggers a differentiated update mechanism, and only loads and synchronizes the target module based on the request event, and non-target modules will continue to use the current version, thereby avoiding the waste of resources and equipment wear caused by the traditional overall rewriting of the storage area. This lightweight update mechanism is very suitable for devices with limited resources, can maximize the saving of resources and time, avoid redundant resource consumption, improve system efficiency and reduce system downtime; b. By combining built-in logical snapshots with module rapid recovery strategies, this solution can directly restore damaged modules from the trusted version when the system detects an anomaly, without the need for overall recovery or system restart, significantly shortening the fault response time. Compared with existing technologies that rely on manual intervention or complex recovery operations, this solution provides a more efficient and automated solution, improving system availability and reliability; c. The present invention periodically compares the current logic snapshot of each module with the historical trusted version of the logic snapshot, thereby dynamically monitoring the characteristic parameters and operating status of the module, detecting potential anomalies in real time and accurately locating the source of the problem, ensuring the stability of the system in different operating scenarios. The active built-in logic snapshot and module recovery mechanism further reduces the risk of fault propagation within the system and improves the overall reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0022] Figure 1 A flowchart of a first event-driven BIOS security protection and recovery optimization method provided for an exemplary embodiment of the present invention; Figure 2 A flowchart of a second event-driven BIOS security protection and recovery optimization method provided for an exemplary embodiment of the present invention; Figure 3 The modules divided by the BIOS system and the dependency chain created are provided for an exemplary embodiment of the present invention; Figure 4 A schematic diagram of a differential update mechanism provided for an exemplary embodiment of the present invention; Figure 5 A schematic diagram of a module recovery strategy based on a logical snapshot provided for an exemplary embodiment of the present invention; Figure 6 A flowchart of a built-in logical snapshot and quick recovery strategy provided for an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, device, product or equipment that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0025] The traditional BIOS update method relies on the rewriting operation of the entire storage area, which not only increases the resource consumption during the update, but also accelerates the wear of the storage device. The present invention adopts an event-driven differential update mechanism, which analyzes the changes in the characteristic parameters of the module and only updates the changed modules, avoiding redundant operations and greatly reducing resource consumption and the cost of using storage devices. Based on this, the present application proposes an event-driven BIOS security protection and recovery optimization method to optimize the resource consumption of BIOS.

[0026] In one embodiment of the present invention, a BIOS security protection and recovery optimization method based on event-driven is provided. Figure 1 , Figure 2 and Figure 4 , the method comprises the following steps: Divide the BIOS into multiple modules according to logical functions, and establish a dependency chain of each module according to the logical relationship between each module, wherein the dependency chain includes the dependency relationship between the module and other modules; Configuring corresponding characteristic parameters for each module, wherein the characteristic parameters include module ID, version information and the dependency relationship; Monitoring a request event that drives the BIOS to work or change, wherein the request event includes a target characteristic parameter, and the target characteristic parameter includes a target module ID, a target version information, and a target dependency relationship; If the target characteristic parameter and each of the characteristic parameters cannot match each other, determine whether there is a module ID that matches the target module ID. If so, determine that the module corresponding to the module ID that matches the target ID is the target module; The target module is driven to change based on the request event, and the characteristic parameters of the target module are updated to target characteristic parameters accordingly.

[0027] The dependency relationship includes the module's dependency on other modules for execution completion and the calling relationship between the module and other modules, etc. The request event includes requesting to add a new module, requesting to delete a module, requesting to modify a module, requesting to update a module version, requesting to fix a vulnerability, requesting to call a module, requesting to run a module, etc.

[0028] BIOS (Basic Input / Output System) is the bridge between computer hardware and operating system. Its main functional modules usually include self-test and initialization module, boot management module, hardware abstraction layer module, setting module, interrupt service module, hardware control module and advanced function module.

[0029] The self-test and initialization module is used for power-on self-test (POST) and hardware initialization: when the computer is turned on, the BIOS will execute the power-on self-test program to check whether the hardware devices are working properly, including the CPU, memory, graphics card, hard disk, keyboard, etc. If a problem is detected, an alarm will be prompted on the screen or a beep sound will sound. After completing the self-test, the BIOS will initialize the configuration of the hardware devices, such as setting interrupt vectors, initializing memory, graphics card, hard disk, etc.

[0030] The boot management module is responsible for booting the operating system. The BIOS will search for the boot device according to the set boot sequence (such as hard disk, USB disk, optical drive, etc.), load the boot record, and hand over the control to the operating system.

[0031] The hardware abstraction layer module provides an interface between the hardware and the operating system, simplifying the operating system's direct operation of the hardware. For example, BIOS provides basic input and output services for hard disks, USB devices, etc.

[0032] The setting module provides a user interface, allowing the user to configure hardware parameters, such as boot sequence, system time, CPU frequency, memory settings, secure boot, etc. These settings are usually stored in CMOS, and the data is maintained by a battery.

[0033] The interrupt service module is responsible for processing hardware interrupt requests and providing a hardware access interface for the operating system and application programs. For example, operations such as disk read and write, keyboard input, etc. all rely on the interrupt service of the BIOS.

[0034] The hardware control module provides low-level control functions for the hardware, such as CPU frequency adjustment, memory timing adjustment, fan speed control, voltage control, etc. These functions are usually used to optimize system performance or perform hardware overclocking.

[0035] The advanced function modules generally include functions such as secure boot, virtualization support, and hard disk health monitoring.

[0036] In one embodiment of the present invention, see Figure 3 Based on the functional logic of each functional module in the BIOS, the BIOS code / system is divided into multiple modules, including a hardware initialization module, a device driver module and a monitoring module, wherein the dependency relationship of the device driver module is that the hardware initialization module is executed first, and the dependency relationship of the monitoring module is that the device driver module is executed first.

[0037] Among them, the hardware initialization module includes the functional modules involved in hardware initialization in the BIOS, such as the above-mentioned self-test and initialization module. The device driver module includes the functional modules involved in device driver in the BIOS, such as the above-mentioned boot management module, hardware abstraction layer module, setting module and hardware control module. The monitoring module is configured to monitor the operating status and changes of other modules to generate logical snapshots corresponding to the modules. Specifically, the monitoring module may include the above-mentioned advanced functional modules. Of course, in other embodiments, the various functional modules of the BIOS may also be divided in other forms, such as being divided into finer self-test and initialization modules, boot management modules, hardware abstraction layer modules, setting modules, hardware control modules and monitoring modules.

[0038] After the BIOS is divided into modules and the dependency chains of each module are established according to the logical relationship between each module, the dependency relationship of each module on other modules is obtained, and corresponding characteristic parameters are generated for each module. The characteristic parameters, as the "identity identification" of the module, preferably include module ID (or module name), version information, dependency relationship, number of calls and running status, etc. Among them, the module ID of each module is unique. Through the module ID, each module can be accurately matched, and by establishing a call relationship or dependency chain between modules, the role and update requirements of the functional module can be dynamically identified when the system is running. Among them, the number of calls can be used to determine whether there is an abnormality in the module. The modular design decomposes the complex BIOS code according to logic, which is conducive to differentiated management. When updating, the scope of the target change module can be accurately located to reduce redundant processing.

[0039] During the operation of the BIOS system, request events include two situations: driving the corresponding module to work and driving the corresponding module to change. Among them, the driver module change includes adding a new module, deleting a module, updating a module, patching a vulnerability in a module, etc.

[0040] The present invention configures the target characteristic parameters for the request event, and the target characteristic parameters include the target module ID, the target version information and the target dependency. If the target characteristic parameters match the characteristic parameters, it means that the request event is used to drive the module to work and run, and does not involve the modification of the module, so there is no need to change the module, and the request event drives the matching module to work.

[0041] It should be noted that the characteristic parameters correspond to the modules one by one, that is, there are multiple characteristic parameters. In one embodiment of the present invention, a request event may include multiple target characteristic parameters or may only include one target characteristic parameter. If there is only one target characteristic parameter, the target characteristic parameter matches any one of the multiple characteristic parameters, and the target characteristic parameter matches the characteristic parameter; if the number of the target characteristic parameters is multiple, each target characteristic parameter is matched with multiple characteristic parameters to obtain a matching result, and some of the target characteristic parameters may match the characteristic parameters, and other target parameters may not match the characteristic parameters. In another embodiment of the present invention, the request event can be narrowed down on the basis of the above embodiment to determine that a request event only includes one target characteristic parameter. The target characteristic parameter matches the characteristic parameter in a one-to-one manner, which means that the information contained in the target characteristic parameter corresponds to the information contained in the characteristic parameter. In a specific embodiment of the present invention, the target module ID is consistent with the module ID, the target version information is consistent with the version information, and the target dependency is consistent with the dependency, which means that the target characteristic parameter matches the characteristic parameter.

[0042] If the target characteristic parameter and each characteristic parameter cannot match each other, it means that the request event is used to drive the corresponding module to change, such as Figure 1 and Figure 2 The further step is to determine whether there is a module ID that matches the target module ID. If so, the module corresponding to the module ID that matches the target ID is determined to be the target module, i.e., the target modified module. Figure 4As shown, the differential update mechanism is triggered, and only the target module is loaded and synchronized based on the request event, and the non-target module will continue to use the current version, thereby maximizing resource and time savings and avoiding redundant resource consumption. The BIOS module change (usually update or patch vulnerability) process is optimized accordingly to improve system efficiency. The update process is driven by system operation events and differentiated processing is performed in combination with the dynamic changes of module characteristic parameters.

[0043] Record change log after update is completed: After the update is completed, the system (completed by the monitoring module in the system in this embodiment) will record all change operations, generate an update log, and update the characteristic parameters of the module, including dependencies and version information.

[0044] To further improve the security of BIOS, see Figure 1 The event-driven BIOS security protection and recovery optimization method further includes the following steps: If there is no module ID that matches the target module ID, determine whether the type of the request event is a newly added module. If so, perform a security check on the request event. If the check passes, add a corresponding functional module based on the request event. If the type of the request event is not a new module, or the security check of the request event fails, the request event is ignored.

[0045] In other embodiments, for BIOS with higher security requirements, see Figure 2 The event-driven BIOS security protection and recovery optimization method further includes the following steps: If there is no module ID that matches the target module ID, the request event is ignored.

[0046] To further improve BIOS security and optimize BIOS recovery, see Figure 5 and Figure 6 The event-driven BIOS security protection and recovery optimization method also includes a built-in logical snapshot and a quick recovery strategy.

[0047] The goals of the built-in logical snapshot and quick recovery strategy include: (1) When a module fails or fails, the system can be quickly restored to its normal state by restoring the trusted version from the logical snapshot to replace the current version of the module; (2) During normal BIOS operation, it can proactively monitor the security risks of each module and proactively replace the current version of the module with a secure and reliable trusted version before the system becomes abnormal.

[0048] See also Figure 5During the operation of the BIOS, a logical snapshot corresponding to each module is generated regularly, and the logical snapshot includes characteristic parameters and operation status, and the operation status includes normal operation and abnormal operation.

[0049] Built-in logical snapshots and quick recovery strategies are key mechanisms for the system to quickly recover to a stable state when faced with failures or anomalies. The implementation process includes multiple steps such as the creation, storage, comparison, and recovery of logical snapshots.

[0050] Logical snapshots are a recording mechanism that records the status of each module at a specific moment. Whenever the system is in a stable state, the core characteristic parameters and operating status of the module are saved through logical snapshots. These logical snapshots provide the basis for rapid recovery. When encountering a failure, the system can restore the module from the most recent valid logical snapshot. The recovery operation does not require restarting the system, but only needs to overwrite the affected module, thus avoiding the impact on the overall system and avoiding the waste of resources for a full recovery of the system.

[0051] Creation of a logical snapshot: First, an initial logical snapshot corresponding to the module of the initial version is created, and the initial logical snapshot includes the characteristic parameters, operating status and core code.

[0052] After that, the system can create a logical snapshot through a timing strategy (such as every certain period of time, every time the module status changes). For example, a logical snapshot is generated every hour, every time the system starts, or according to user operations. In order to save storage space, an incremental logical snapshot method is used to regularly generate a logical snapshot corresponding to the module, including recording the parts that have changed compared to the previous version of the logical snapshot, including the changed characteristic parameters, operating status and code. In this way, the storage space of the logical snapshot is optimized.

[0053] More preferably, the logical snapshot of each module includes the following key data: Feature parameters: The version information includes the version number of the module, so as to determine whether it is a trusted version during recovery; Running status: including the actual running status of the module, such as normal operation, abnormal operation, memory usage, configuration, dependencies, etc. Module log: including module execution history, operation log and exception record, etc.; File system status: Saves the file directory structure of the module or system and the checksum of key files, which is used to check the file integrity during recovery.

[0054] The implementation process of the fast recovery strategy includes: determining the recovery condition, responding to the recovery condition, and starting the recovery strategy.

[0055] The recovery conditions can be either of the following: (1) Determining that the module is abnormal; (2) Determining that the module is abnormal and cannot be repaired by itself.

[0056] In one embodiment of the present invention, condition (2) is taken as an example for description.

[0057] Module abnormality means that when a module has a functional abnormality such as loss of function, configuration mismatch, or inability to load, the system / monitoring module will determine whether the module needs to be restored. To determine whether a module is abnormal, the system monitors the operating status and characteristic parameters of each module, such as version information, call frequency, memory usage, etc., through the monitoring module to detect whether the module is abnormal in real time. For example, if the system detects that the version information of the module is inconsistent with the version information in the logical snapshot, or the functional status of the module is abnormal (such as failure to start or crash), the module recovery mechanism is triggered.

[0058] When the system detects that a module is abnormal and cannot be repaired by itself, a "recovery flag" will be set, that is, the module needs to be restored from the logical snapshot. Once it is determined that the module needs to be restored, the module recovery mechanism is triggered, including: determining that the module version with normal operation status is a trusted version through the logical snapshot; replacing the current version of the module with the trusted version, and updating the characteristic parameters of the module accordingly. Preferably, the most recent trusted version is selected to replace the current version of the module.

[0059] The logic snapshot is configured to be stored in the NVRAM area of ​​the BIOS. When the module recovery mechanism is triggered, the logic snapshot of the secure version corresponding to the module to be recovered is loaded from the NVRAM area to overwrite the current module.

[0060] Replacing the current version of the module with the trusted version includes: determining abnormal data in the current version of the module by comparing the current version of the module with the trusted version; and overwriting the abnormal data with corresponding data in the trusted version.

[0061] After replacing the current version of the module with the trusted version, the logical snapshot of the replaced module is compared with the logical snapshot corresponding to the trusted version to ensure that the restored version matches the restoration target.

[0062] Overwrite the damaged or tampered part of the current module with the trusted version saved in the logical snapshot. This step usually does not restart the entire system, but only repairs a single module. Unlike traditional full disk recovery, fast recovery only recovers the problematic module. This means that only the affected module will be overwritten and other modules do not need to be affected. Therefore, through the built-in logical snapshot and fast recovery strategy, this solution can directly restore the damaged module from the trusted version when the system detects an anomaly, without the need for overall recovery or system restart, significantly shortening the fault response time. Compared with existing technologies that rely on manual intervention or complex recovery operations, this solution provides a more efficient and automated solution, improving the availability and reliability of the system.

[0063] In an embodiment of the present invention, not only is the abnormal module determined by functional abnormality as in the above embodiment, but also active determination of whether each module is abnormal or not is included.

[0064] In this embodiment, if Figure 6 As shown, during the operation of the BIOS, logical snapshots corresponding to each module are generated periodically. The module version whose operating status is normal is determined to be a trusted version through the previous logical snapshot. For each module, after the latest logical snapshot is generated, the latest logical snapshot is compared with the logical snapshot corresponding to the most recent trusted version. If the comparison is consistent, the current module is determined to be normal, otherwise the current module is determined to be an untrusted module. For the untrusted module, a security check is performed on the module. If the check passes, the untrusted module is determined to be normal, otherwise, the untrusted module is determined to be abnormal. The present invention does not limit the specific method of security verification for the module, for example, verification by security key, manual verification or encryption method, etc.

[0065] Likewise, when it is determined that a module is abnormal and cannot be repaired by itself, a module recovery mechanism is triggered, the current version of the module is replaced by the trusted version, and the characteristic parameters of the module are updated accordingly.

[0066] The above-mentioned built-in logical snapshot and quick recovery strategy are described below through a specific embodiment. In this embodiment, the BIOS of the device includes multiple functional modules, one of which is a network driver module. This module is responsible for communicating with the network hardware when the BIOS is started. The stability of the module is protected by the built-in logical snapshot mechanism, and it can be quickly restored when an abnormality occurs.

[0067] The process of creating a logical snapshot is as follows.

[0068] Initial logical snapshot creation: When the device starts, the BIOS automatically generates an initial logical snapshot, recording the characteristic parameters of the network driver module (including module ID, version information, etc.), configuration files, code, memory status and other related system status. These data will be saved in the NVRAM area of ​​the BIOS.

[0069] Saved content: module characteristic parameters, configuration files, codes, IP address configuration, network hardware status (such as MAC address), and call logs, etc.

[0070] Periodic logical snapshot creation: During system operation, whenever the network driver module is updated (such as driver version upgrade, configuration change), the system automatically creates an incremental logical snapshot to save the new state of the network driver module. At this time, only the parts that have changed compared with the last logical snapshot (such as new configuration parameters, memory status, etc.) are recorded, and all data of the entire module will not be overwritten.

[0071] Abnormal detection and triggered recovery: When the system detects that the network driver module cannot work properly (such as unable to connect to the network, abnormal configuration, etc.), the system will mark the module as "abnormal". At this time, the system will find the problem and prepare for recovery by comparing the current state and the version information of the logical snapshot.

[0072] The logical snapshot recovery process is as follows.

[0073] Recovery trigger: When a network driver module is abnormal, the system automatically loads the latest trusted version of the module from the logical snapshot stored in the NVRAM area and overwrites the current error / abnormal module.

[0074] Recovery operation: Only the affected network driver module is restored, and other system modules will not be affected. The recovery operation is very fast, avoiding system restart and not causing excessive consumption of system performance.

[0075] This solution dynamically monitors the status changes of each BIOS module through functional feature analysis and modular management to ensure the integrity and operation safety of key codes. Even if an attacker successfully bypasses the peripheral protection, he cannot break through the strict verification of module features, thereby significantly improving the system's ability to resist tampering and malicious attacks. Compared with existing traditional technologies such as password protection, hardware binding and digital signatures, this solution provides stronger protection capabilities and reduces the risk of attacks caused by fixed verification logic. This lightweight dynamic verification and recovery mechanism can operate efficiently in scenarios with limited computing and storage resources. For example, through hierarchical protection of functional modules and adaptive update strategies, this solution can provide stable and efficient protection capabilities in resource-constrained environments such as embedded devices and IoT terminals, which is more flexible and practical than existing technologies.

[0076] In one embodiment of the present invention, a BIOS system is provided, wherein the BIOS system is configured to perform security protection and abnormal recovery using an event-driven BIOS security protection and recovery optimization method as described in any one or more of the above embodiments.

[0077] In one embodiment of the present invention, a computer system is provided, wherein the computer system includes the BIOS system described in the above embodiment.

[0078] It should be noted that the BIOS system and computer system embodiments provided by the present invention are the same as the inventive concept of the above-mentioned event-driven BIOS security protection and recovery optimization method embodiment, and all the contents of the event-driven BIOS security protection and recovery optimization method embodiment are incorporated into the BIOS system and computer system embodiments by introduction.

[0079] Due to the advanced nature of this technical solution, it can be widely used in application fields such as computer system security, embedded device development and data recovery. In the field of computer system security, the partition management strategy, differential update method, built-in logical snapshot and fast recovery function of the present invention can effectively improve the security, stability and reliability of the system. Especially in some fields with extremely high security requirements, such as finance, medical care and government departments, the application of the present invention can significantly improve the protection ability of the system, prevent unauthorized access and malicious modification, and ensure the normal operation of the system.

[0080] In the field of embedded device development, the present invention is optimized for scenarios with limited resources, and its differential update method and quick recovery function can significantly reduce resource usage, reduce equipment wear and energy consumption, and improve equipment reliability and service life. Therefore, the present invention has broad application prospects in embedded device fields such as smart homes, wearable devices, and industrial control systems. In the field of data recovery, the quick recovery function and differential update method of the present invention can significantly shorten the time of data recovery and improve recovery efficiency. In particular, in some scenarios with high requirements for data recovery speed, such as big data analysis and cloud computing, the application of the present invention can significantly improve the availability and performance of the system.

[0081] In general, with the continuous development of computer system security, embedded device development and data recovery, the demand for efficient, safe and reliable BIOS protection solutions is increasing. The application prospect of the present invention is broad and the market demand is strong, and it is expected to play an important role in these fields.

[0082] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0083] The above is only a specific implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A BIOS security protection and recovery optimization method based on event-driven, characterized in that: The following steps are involved: Divide the BIOS into multiple modules according to logical functions, and establish a dependency chain of each module according to the logical relationship between each module, wherein the dependency chain includes the dependency relationship between the module and other modules; Configuring corresponding characteristic parameters for each module, wherein the characteristic parameters include module ID, version information and the dependency relationship; Monitoring a request event that drives the BIOS to work or change, wherein the request event includes a target characteristic parameter, and the target characteristic parameter includes a target module ID, a target version information, and a target dependency relationship; If the target characteristic parameter and each of the characteristic parameters cannot match each other, determine whether there is a module ID that matches the target module ID. If so, determine that the module corresponding to the module ID that matches the target ID is the target module; The target module is driven to change based on the request event, and the characteristic parameters of the target module are updated to target characteristic parameters accordingly.

2. The event-driven BIOS security protection and recovery optimization method according to claim 1, characterized in that: The following steps are also included: If the target characteristic parameter cannot match each of the characteristic parameters, and there is no module ID that matches the target module ID, determine whether the type of the request event is a newly added module. If so, perform a security check on the request event. If the check passes, add a corresponding functional module based on the request event. If the type of the request event is not a new module, or the security check of the request event fails, the request event is ignored.

3. The event-driven BIOS security protection and recovery optimization method according to claim 1, characterized in that: The following steps are also included: If the target characteristic parameter cannot match any of the characteristic parameters, and there is no module ID that matches the target module ID, the request event is ignored.

4. The event-driven BIOS security protection and recovery optimization method according to claim 1, characterized in that: The following steps are also included: If the target characteristic parameter matches the characteristic parameter, the matching module is driven to operate according to the request event.

5. The event-driven BIOS security protection and recovery optimization method according to claim 1, characterized in that: The following steps are also included: During the operation of the BIOS, a logical snapshot corresponding to each module is generated periodically, wherein the logical snapshot includes characteristic parameters and operation status, and the operation status includes normal operation and abnormal operation; When the module is tampered with or has an abnormality, the module recovery mechanism is triggered, including: Determining through the logical snapshot that the module version whose running status is normal is a trusted version; The current version of the module is replaced with the trusted version, and characteristic parameters of the module are updated accordingly.

6. The event-driven BIOS security protection and recovery optimization method according to claim 5, characterized in that: Replacing a current version of the module with the trusted version includes: Determining abnormal data in the current version of the module by comparing the current version of the module with the trusted version; The abnormal data is overwritten with the corresponding data in the trusted version.

7. The event-driven BIOS security protection and recovery optimization method according to claim 1, characterized in that: The following steps are also included: During the operation of the BIOS, a logical snapshot corresponding to each module is generated periodically, wherein the logical snapshot includes characteristic parameters and operation status, and the operation status includes normal operation and abnormal operation; Determining through the previous logical snapshot that the module version whose running status is normal is a trusted version; For each module, after generating the latest logical snapshot, the latest logical snapshot is compared with the logical snapshot corresponding to the most recent trusted version. If the comparison is consistent, the current module is determined to be normal, otherwise the current module is determined to be an untrusted module.

8. The event-driven BIOS security protection and recovery optimization method according to claim 7, characterized in that: The following steps are also included: For the untrusted module, a security check is performed on the module. If the check passes, it is determined that the untrusted module is normal. Otherwise, it is determined that the untrusted module is abnormal, and the current version of the untrusted module is replaced by the trusted version, and the characteristic parameters of the untrusted module are updated accordingly.

9. The event-driven BIOS security protection and recovery optimization method according to claim 5 or 7, characterized in that: The logical snapshots corresponding to the modules are generated regularly in the following ways: Creating a corresponding initial logic snapshot based on the module of the initial version, wherein the initial logic snapshot includes the characteristic parameters, operating status and code; An incremental logic snapshot method is used to periodically generate logic snapshots corresponding to the module, including recording the parts that have changed compared to the previous version of the logic snapshot, including the changed characteristic parameters, operating status and code.

10. The event-driven BIOS security protection and recovery optimization method according to claim 5 or 7, characterized in that: The logical snapshot is configured to be stored in the NVRAM area of ​​the BIOS. When the module recovery mechanism is triggered, the trusted version corresponding to the module to be recovered is loaded from the NVRAM area, and the current version of the module is overwritten with the trusted version.

11. The event-driven BIOS security protection and recovery optimization method according to claim 5 or 7, characterized in that: The modules include a hardware initialization module, a device driver module and a monitoring module, wherein the dependency relationship of the device driver module is that it depends on the hardware initialization module to be executed first, and the dependency relationship of the monitoring module is that it depends on the device driver module to be executed first; The monitoring module is configured to monitor the operating status and changes of other modules to generate a logical snapshot corresponding to the module, wherein the logical snapshot includes characteristic parameters and operating status.

12. A BIOS system, characterized in that: The BIOS system is configured to perform security protection and abnormal recovery using the event-driven BIOS security protection and recovery optimization method as described in any one of claims 1 to 11.

13. A computer system, characterized in that: The computer system includes the BIOS system as claimed in claim 12.

Images