Event-driven BIOS Security Protection and Recovery Optimization Method and System

Abstract

The present invention discloses an event-driven BIOS security protection and recovery optimization method and system. The method includes dividing the BIOS into multiple modules according to logical functions, establishing a dependency chain for each module based on the logical relationship between each module, and the dependency chain includes the dependency relationship between the module and other modules; configuring characteristic parameters for each module, including module ID, version information, and dependency relationship; monitoring a request event that drives the BIOS to work or change, and the request event includes target characteristic parameters containing a target module ID, target version information, and target dependency relationship; if the target characteristic parameters cannot be matched and consistent with each characteristic parameter, determine whether there is a module ID that matches the target module ID, and if so, determine the module with the module ID that is consistent with the target ID as the target module; driving the target module to change and update its characteristic parameters based on the request event. The present invention can efficiently update the system and improve the security of the system.

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] The security of computer systems is one of the important research directions in the field of modern information technology. As the software that runs first during the startup process of a computer system, the security of the BIOS (Basic Input / Output System) directly affects the security of the entire system. BIOS protection technology aims to prevent unauthorized access and malicious modification, ensuring 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, which can quickly restore the system or data to its normal state when the system fails or data is damaged.

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

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

[0005] The disclosure of the above background art content is only for assisting in understanding the inventive concept and technical solution of the present invention, and it does not necessarily belong to the prior art of this application, nor will it necessarily give technical guidance; without clear evidence indicating that the above content was publicly available before the filing date of this application, the above background art should not be used to evaluate the novelty and inventiveness of this 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 system security.

[0007] To achieve the above object, the technical solution adopted by the present invention is as follows:

[0008] An event-driven BIOS security protection and recovery optimization method, comprising the following steps:

[0009] The BIOS is divided into multiple modules according to logical functions, and a dependency chain of each module is established according to the logical relationship between the modules. The dependency chain includes the dependency relationship between the module and other modules;

[0010] Corresponding characteristic parameters are configured for each of the modules. The characteristic parameters include a module ID, version information, and the dependency relationship;

[0011] Monitor a request event that drives the BIOS to work or change. The request event includes target characteristic parameters, and the target characteristic parameters include a target module ID, target version information, and a target dependency relationship;

[0012] If the target characteristic parameters do not match any of the characteristic parameters, determine whether there is a module ID that matches the target module ID. If there is, determine the module corresponding to the module ID that matches the target ID as the target module;

[0013] Drive the target module to change based on the request event, and correspondingly update the characteristic parameters of the target module to the target characteristic parameters.

[0014] Further, continuing from any one of the above technical solutions or a combination of multiple technical solutions, the method further comprises the following steps:

[0015] If the target characteristic parameters do not match any 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 new 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;

[0016] If the type of the request event is not a new module, or the security check on the request event fails, ignore the request event.

[0017] Further, continuing from any one of the above technical solutions or a combination of multiple technical solutions, the method further comprises the following steps:

[0018] If the target characteristic parameters do not match any of the characteristic parameters, and there is no module ID that matches the target module ID, ignore the request event.

[0019] Further, continuing from any one of the above technical solutions or a combination of multiple technical solutions, the method further comprises the following steps:

[0020] If the target feature parameter matches the feature parameter, the module that matches is driven to work according to the request event.

[0021] Further, based on any one of the foregoing technical solutions or a combination of multiple technical solutions, the following steps are further included:

[0022] During the operation of the BIOS, logical snapshots corresponding to each module are regularly generated. The logical snapshots include feature parameters and operating statuses, and the operating statuses include normal operation and abnormal operation.

[0023] When the module is tampered with or there is an abnormality, a module recovery mechanism is triggered, including:

[0024] Determine that the module version with a normal operating status in the logical snapshot is a trusted version.

[0025] Use the trusted version to replace the current version of the module and update the feature parameters of the module accordingly.

[0026] Further, based on any one of the foregoing technical solutions or a combination of multiple technical solutions, using the trusted version to replace the current version of the module includes:

[0027] Determine the abnormal data in the current version of the module by comparing the current version of the module with the trusted version.

[0028] Use the corresponding data in the trusted version to overwrite the abnormal data.

[0029] Further, based on any one of the foregoing technical solutions or a combination of multiple technical solutions, the following steps are further included:

[0030] During the operation of the BIOS, logical snapshots corresponding to each module are regularly generated. The logical snapshots include feature parameters and operating statuses, and the operating statuses include normal operation and abnormal operation.

[0031] Determine that the module version with a normal operating status in the foregoing logical snapshot is a trusted version.

[0032] For each module, after generating the latest logical snapshot, compare the latest logical snapshot with the logical snapshot corresponding to the most recent trusted version. If the comparison is consistent, determine that the current module is normal; otherwise, determine that the current module is a non-trusted module.

[0033] Further, based on any one of the foregoing technical solutions or a combination of multiple technical solutions, the following steps are further included:

[0034] For the untrusted module, perform a security check on the module. If the check passes, determine that the untrusted module is normal and do not change the untrusted module; otherwise, determine that the untrusted module is abnormal, and use the trusted version to replace the current version of the untrusted module, and accordingly update the characteristic parameters of the untrusted module.

[0035] Further, based on any one of the foregoing technical solutions or a combination of multiple technical solutions, regularly generate a corresponding logical snapshot of the module in the following manner:

[0036] Create an initial logical snapshot corresponding to the module based on the initial version of the module. The initial logical snapshot includes the characteristic parameters, operating status, and core code.

[0037] Adopt an incremental logical snapshot method to regularly generate a corresponding logical snapshot of 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.

[0038] Further, based on any one of the foregoing technical solutions or a combination of multiple technical solutions, the logical snapshot is configured to be stored in the NVRAM area of the BIOS. When the module recovery mechanism is triggered, load the trusted version corresponding to the module to be recovered from the NVRAM area, and use the trusted version to overwrite the current version of the module.

[0039] Further, based on any one of the foregoing technical solutions or a combination of multiple technical solutions, the module includes a hardware initialization module, a device driver module, and a monitoring module. Among them, the dependency relationship of the device driver module is that it depends on the hardware initialization module to execute first, and the dependency relationship of the monitoring module is that it depends on the device driver module to execute first;

[0040] Among them, the monitoring module is configured to monitor the operating status and changes of other modules to generate a corresponding logical snapshot of the module. The logical snapshot includes characteristic parameters and operating status.

[0041] According to another aspect of the present invention, the present application provides a BIOS system, and the BIOS system is configured to perform security protection and abnormal recovery by using the event-driven BIOS security protection and recovery optimization method according to any one of the foregoing technical solutions or a combination of multiple technical solutions.

[0042] According to another aspect of the present invention, the present application provides a computer system, and the computer system includes the BIOS system according to any one of the foregoing technical solutions or a combination of multiple technical solutions.

[0043] The beneficial effects brought by the technical solution provided by the present invention are as follows:

[0044] a. By comparing and matching the target feature parameters corresponding to the request event with the feature parameters corresponding to each module, the present invention determines that the request event is an event that drives the corresponding module to change according to the result that no match is found, and accurately locates the target module that needs to be changed based on the comparison result of the feature parameters, triggers the differential update mechanism, and only loads and synchronizes the target module based on the request event. The non-target modules will continue to use the current version, avoiding the resource waste and device wear caused by the traditional overall rewrite of the storage area. This lightweight update mechanism is very suitable for devices with limited resources, can maximize resource and time savings, avoid redundant resource consumption, improve system efficiency, and reduce system downtime;

[0045] b. By combining the built-in logical snapshot and the module quick recovery strategy, the present solution can directly recover 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 the 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;

[0046] c. By regularly comparing the current logical snapshot of each module with the historical trusted version logical snapshot, the present invention can dynamically monitor the feature parameters and operating status of the module, detect potential anomalies in real time, and accurately locate the source of the problem, ensuring the stability of the system in different operating scenarios. This proactive built-in logical 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

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0048] Figure 1 The flowchart of the first event-driven BIOS security protection and recovery optimization method provided for an exemplary embodiment of the present invention;

[0049] Figure 2 The flowchart of the second event-driven BIOS security protection and recovery optimization method provided for an exemplary embodiment of the present invention;

[0050] Figure 3The module divided by the BIOS system and the created dependency chain provided for an exemplary embodiment of the present invention;

[0051] Figure 4 The schematic diagram of the differential update mechanism provided for an exemplary embodiment of the present invention;

[0052] Figure 5 The schematic diagram of the module recovery strategy based on logical snapshot provided for an exemplary embodiment of the present invention;

[0053] Figure 6 The flowchart of the built-in logical snapshot and fast recovery strategy provided for an exemplary embodiment of the present invention. Detailed implementation manners

[0054] In order to enable those skilled in the art of the present technology to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0055] 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 do not have to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances 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 "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, device, product or equipment comprising a series of steps or units does not have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or equipment.

[0056] Traditional BIOS update methods rely on the rewrite 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. By analyzing the changes in the characteristic parameters of the module, only the changed module is updated, avoiding redundant operations and greatly reducing the resource consumption and the usage cost of the storage device. Based on this, the present application proposes an event-driven BIOS security protection and recovery optimization method to optimize the resource consumption of the BIOS.

[0057] In an embodiment of the present invention, an event-driven BIOS security protection and recovery optimization method is provided. SeeFigure 1 , Figure 2 and Figure 4 , the method includes the following steps:

[0058] Divide the BIOS into multiple modules according to logical functions, and establish a dependency chain for each module according to the logical relationship between the modules. The dependency chain includes the dependency relationship between the module and other modules;

[0059] Configure corresponding characteristic parameters for each of the modules. The characteristic parameters include module ID, version information, and the dependency relationship;

[0060] Monitor a request event that drives the BIOS to work or change. The request event includes target characteristic parameters. The target characteristic parameters include a target module ID, target version information, and a target dependency relationship;

[0061] If the target characteristic parameters do not match any of the characteristic parameters, determine whether there is a module ID that matches the target module ID. If there is, determine the module corresponding to the module ID that is the same as the target ID as the target module;

[0062] Drive the target module to change based on the request event, and correspondingly update the characteristic parameters of the target module to the target characteristic parameters.

[0063] Among them, the dependency relationship includes that the module depends on the completion of other modules and the call relationship between the module and other modules, etc. The request event includes a request to add a module, a request to delete a module, a request to modify a module, a request to update the module version, a request to patch a vulnerability, a request to call a module, a request to run a module, and so on.

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

[0065] Among them, the self-check and initialization module is used for power-on self-check (POST) and hardware initialization: when the computer is powered on, the BIOS will execute the power-on self-check 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, it will give an alarm through a screen prompt or a beep. After the self-check is completed, the BIOS will perform initialization configuration on the hardware devices, such as setting interrupt vectors, initializing memory, graphics card, hard disk, etc.

[0066] The described boot management module is responsible for booting the operating system. The BIOS searches for the boot device according to the set boot order (such as hard disk, USB drive, optical drive, etc.), loads the boot record, and hands over the control to the operating system.

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

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

[0069] The interrupt service module is responsible for handling hardware interrupt requests and providing a hardware access interface for the operating system and applications. For example, operations such as disk read / write and keyboard input rely on the interrupt service of the BIOS.

[0070] 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 overclock the hardware.

[0071] The advanced function module usually includes functions such as Secure Boot, virtualization support, hard disk health monitoring, etc.

[0072] In an embodiment of the present invention, refer to 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. Among them, 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.

[0073] Among them, the hardware initialization module includes the functional modules in the BIOS related to hardware initialization, for example, including the above self-check and initialization module. The device driver module includes the functional modules in the BIOS related to device drivers. For example, it includes the above-mentioned boot management module, hardware abstraction layer module, settings module, and hardware control module. The monitoring module is configured to monitor the running status and changes of other modules to generate a corresponding logical snapshot of the module. Specifically, the monitoring module may include the above-mentioned advanced function module. Of course, in other embodiments, the various functional modules of the BIOS can also be divided in other forms. For example, they can be further divided into a more detailed self-check and initialization module, boot management module, hardware abstraction layer module, settings module, hardware control module, and monitoring module.

[0074] After partitioning the BIOS into modules and establishing the dependency chain for each module based on the logical relationships between the modules to obtain the dependencies of each module on other modules, corresponding characteristic parameters are generated for each module. The characteristic parameters serve as the "identity identifiers" of the modules and preferably include module IDs (or module names), version information, dependencies, call counts, and running states, etc. Among them, the module IDs of each of the modules are unique. Precise matching of each module can be achieved through the module ID, and call relationships or dependency chains are established between the modules so that the roles and update requirements of the functional modules can be dynamically recognized during system operation. Among them, the call count can be used to determine whether there are any abnormalities in the module. The modular design decomposes the complex BIOS code logically, which is conducive to differential management. During updates, the scope of the target changed module can be accurately located, reducing redundant processing.

[0075] During the operation of the BIOS system, the request events include two situations: driving the corresponding module to work and driving the corresponding module to change. Among them, driving the module to change includes adding a module, deleting a module, updating a module, patching vulnerabilities in the module, and so on.

[0076] In the present invention, target characteristic parameters are configured for the request events, and the target characteristic parameters include the target module ID, target version information, and target dependencies. If the target characteristic parameters match the characteristic parameters, it indicates that the request event is used to drive the module to work and run without involving modification of the module, so there is no need to change the module, and the module that matches consistently is driven to work according to the request event.

[0077] It should be noted that the characteristic parameters correspond to the modules one by one, that is, there are multiple characteristic parameters. In an 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 the characteristic parameter if the target characteristic parameter matches any one of the multiple characteristic parameters; if the number of the target characteristic parameters is multiple, each target characteristic parameter is respectively matched with the multiple characteristic parameters to obtain a matching result. It is possible that some of the target characteristic parameters match the characteristic parameters, and some of the other target parameters do 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, and it is determined that a request event only includes one target characteristic parameter. The meaning that the target characteristic parameter matches the characteristic parameter is that the information contained in the target characteristic parameter corresponds to the information contained in the characteristic parameter one by one. 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 relationship is consistent with the dependency relationship, which indicates that the target characteristic parameter matches the characteristic parameter.

[0078] If the target characteristic parameter cannot match any of the characteristic parameters, it means that the request event is used to drive the corresponding module to change, such as Figure 1 and Figure 2 further determine whether there is a module ID that matches the target module ID. If there is, determine the module corresponding to the module ID that is consistent with the target ID as the target module, that is, the module to be modified. Such as Figure 4 shown, trigger the differential update mechanism, and only load and synchronize the target module based on the request event. The non-target modules will continue to use the current version, so as to maximize resource and time savings, avoid redundant resource consumption, and optimize the BIOS module change (usually update or patch vulnerabilities) process accordingly, improving system efficiency. The update process is driven by system operation events and differential processing is performed in combination with the dynamic changes of module characteristic parameters.

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

[0080] To further improve the security of the BIOS, see Figure 1 , the event-driven BIOS security protection and recovery optimization method further includes the following steps:

[0081] If there is no match between the module ID and the target module ID, it is determined whether the type of the request event is to add a module. If so, security verification is performed on the request event. If the verification passes, the corresponding functional module is added based on the request event.

[0082] If the type of the request event is not to add a module, or the security verification of the request event fails, the request event is ignored.

[0083] In other embodiments, for a BIOS with higher security requirements, refer to Figure 2 , the event-driven BIOS security protection and recovery optimization method further includes the following steps:

[0084] If there is no match between the module ID and the target module ID, the request event is ignored.

[0085] To further improve the security of the BIOS and optimize the recovery of the BIOS, refer to Figure 5 and Figure 6 , the event-driven BIOS security protection and recovery optimization method further includes built-in logical snapshots and fast recovery strategies.

[0086] The goals of the built-in logical snapshots and fast recovery strategies include:

[0087] (1) When a module fails or is abnormal, the trusted version is restored from the logical snapshot to replace the current version of the module, realizing a quick recovery of the normal state of the system;

[0088] (2) During the normal operation of the BIOS, the security risks of each module can be actively monitored, and the current version of the module can be actively replaced with a secure and reliable trusted version before the system becomes abnormal.

[0089] Refer to Figure 5 , during the operation of the BIOS, logical snapshots corresponding to each module are regularly generated. The logical snapshots include characteristic parameters and operating states, and the operating states include normal operation and abnormal operation.

[0090] The built-in logical snapshots and fast recovery strategies are the key mechanisms for the system to quickly recover to a stable state in the face of failures or abnormalities. Its implementation process includes multiple links such as the creation, storage, comparison, and recovery of logical snapshots.

[0091] A logical snapshot is a recording mechanism in which the system records the states of various modules at a specific moment. Whenever the system is in a stable state, it saves the core feature parameters and running status of the modules through logical snapshots. These logical snapshots provide the basis for quick recovery. In case of a failure, the system can recover the modules from the most recent valid logical snapshot. The recovery operation does not require restarting the system. Instead, it only needs to overwrite the affected modules, thus avoiding the impact on the overall system and the waste of resources for a full system recovery.

[0092] Creation of logical snapshots: First, an initial logical snapshot corresponding to the module based on the initial version is created. The initial logical snapshot includes the feature parameters, running status, and core code.

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

[0094] More preferably, the logical snapshot of each module includes the following key data:

[0095] Feature parameters: Among them, the version information includes the version number of the module, which is convenient for judging whether it is a trustworthy version during recovery;

[0096] Running status: Includes the actual running status of the module such as normal running, abnormal running, memory usage, configuration, dependencies, etc.;

[0097] Module logs: Include the execution history, operation logs, and exception records of the module, etc.;

[0098] File system status: Saves the file directory structure of the module or system and the checksum of key files, which is used to verify the file integrity during recovery.

[0099] The implementation process of the quick recovery policy includes: determining the recovery conditions and starting the recovery policy in response to the generation of the recovery conditions.

[0100] The recovery conditions can be selected from the following two: (1) determining that the module is abnormal; (2) determining that the module is abnormal and cannot repair itself.

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

[0102] Module exception means that when a certain module has functional abnormalities 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 conditions 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 unable to start or crash), the module recovery mechanism is triggered.

[0103] When the system detects a module exception and cannot repair it by itself, it will set a "recovery flag", 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 the running status of normal operation in the logical snapshot is a trusted version; using the trusted version to replace the current version of the module, and correspondingly updating the characteristic parameters of the module. Preferably, the nearest trusted version is selected to replace the current version of the module.

[0104] The logical snapshot is configured to be stored in the NVRAM area of the BIOS. When the module recovery mechanism is triggered, the logical snapshot of the secure version corresponding to the module that needs to be restored is loaded from the NVRAM area to overwrite the current module.

[0105] Using the trusted version to replace the current version of the module includes: determining the abnormal data in the current version of the module by comparing the current version of the module with the trusted version; using the corresponding data in the trusted version to overwrite the abnormal data.

[0106] After using the trusted version to replace the current version of the module, compare the logical snapshot of the replaced module with the logical snapshot corresponding to the trusted version to ensure that the restored version matches the recovery target.

[0107] Cover 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. Different from traditional full-disk recovery, quick recovery only targets the problematic module for recovery. This means that only the affected module will be overwritten, and other modules will not be affected. Therefore, through the built-in logical snapshot and quick recovery strategy, this solution can directly restore the damaged module from the trusted version when the system detects an abnormality, 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.

[0108] In one embodiment of the present invention, not only is the abnormal module determined by means of abnormal functions as in the above embodiment, but also an active determination is made on whether each module is abnormal.

[0109] In this embodiment, as Figure 6 shown, during the operation of the BIOS, logical snapshots corresponding to each module are periodically generated. The module version with a normal running state determined by the previous logical snapshot is a trusted version. For each module, after the latest logical snapshot is generated, the latest logical snapshot is compared with the logical snapshot corresponding to the nearest trusted version. If the comparison is consistent, it is determined that the current module is normal; otherwise, the current module is determined to be a non-trusted module. For the non-trusted module, a security check is performed on the module. If the check passes, it is determined that the non-trusted module is normal; otherwise, it is determined that the non-trusted module is abnormal. The present invention does not limit the specific manner of the security check for the module. For example, verification through a security key, manual verification, or encryption verification can all be used.

[0110] Similarly, when it is determined that the module is abnormal and cannot be self-repaired, the module recovery mechanism is triggered, and the trusted version is used to replace the current version of the module, and the characteristic parameters of the module are updated accordingly.

[0111] The above built-in logical snapshot and fast recovery strategy are illustrated by a specific embodiment below. In this embodiment, the BIOS of the device includes multiple functional modules, one of which is the network driver module. This module is responsible for communicating with network hardware when the BIOS starts up. The stability of this module is protected by the built-in logical snapshot mechanism, and it can be quickly recovered in case of an abnormality.

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

[0113] Creation of the initial logical snapshot: When the device starts up, the BIOS automatically generates an initial logical snapshot, recording the characteristic parameters (including module ID, version information, etc.), configuration file, code, memory state, and other relevant system states of the network driver module. These data will be saved in the NVRAM area of the BIOS.

[0114] Contents to be saved: Characteristic parameters of the module, configuration file, code, IP address configuration, network hardware status (such as MAC address), and call logs, etc.

[0115] Creation of the periodic logical snapshot: During the operation of the system, 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 previous logical snapshot (such as new configuration parameters, memory state, etc.) are recorded, rather than overwriting all the data of the entire module.

[0116] Anomaly Detection and Triggered Recovery: When the system detects that the network driver module is not working properly (such as unable to connect to the network, configuration anomalies, etc.), the system will mark the module as "abnormal" status. At this time, the system will compare the current status with the version information of the logical snapshot, discover problems and prepare for recovery.

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

[0118] Recovery Trigger: When the network driver module is abnormal, the system will automatically load the latest trusted version of the module from the logical snapshot stored in the NVRAM area and overwrite the current error / abnormal module.

[0119] Recovery Operation: Only the affected network driver module is recovered, 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.

[0120] This solution dynamically monitors the status changes of each BIOS module through functional feature analysis and modular management to ensure the integrity and running security of critical code. Even if an attacker successfully bypasses the peripheral protection, they cannot break through the strict verification of module features, thus significantly enhancing 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 attack risks brought 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, being more flexible and practical than existing technologies.

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

[0122] In an embodiment of the present invention, a computer system is provided, and the computer system includes the BIOS system described in the above embodiment.

[0123] It should be noted that the BIOS system and computer system embodiments provided by the present invention have the same inventive concept as the above-described event-driven BIOS security protection and recovery optimization method embodiments. By introducing, all the content of the event-driven BIOS security protection and recovery optimization method embodiments is incorporated into the BIOS system and computer system embodiments.

[0124] Due to the advancement of this technical solution, it can be widely applied 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 enhance the security, stability, and reliability of the system. Especially in some fields with extremely high security requirements, such as finance, healthcare, 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.

[0125] In the field of embedded device development, the present invention is optimized for scenarios with limited resources. Its differential update method and fast recovery function can significantly reduce resource usage, reduce device wear and energy consumption, and improve device reliability and service life. Therefore, the present invention has broad application prospects in the field of embedded devices such as smart homes, wearable devices, and industrial control systems. In the field of data recovery, the fast recovery function and differential update method of the present invention can greatly shorten the data recovery time and improve the recovery efficiency. Especially 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.

[0126] Generally speaking, with the continuous development of fields such as computer system security, embedded device development, and data recovery, the demand for efficient, secure, and reliable BIOS protection solutions is increasing. The present invention has broad application prospects and strong market demand, and is expected to play an important role in these fields.

[0127] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising a..." does not exclude the existence of additional identical elements in the process, method, article or device comprising the element.

[0128] The above description is only a specific implementation manner of this application. It should be pointed out that for those of ordinary skill in the art of this technology, without departing from the principle of this application, several improvements and refinements can still be made, and these improvements and refinements should also be regarded as the protection scope of this application.

Claims

1. An event-driven BIOS security protection and recovery optimization method, characterized in that It includes the following steps: The BIOS is divided into multiple modules according to logical functions, and a dependency chain for each module is established based on the logical relationship between the modules. The dependency chain includes the dependency relationships between the module and other modules; Corresponding characteristic parameters are configured for each of the modules. The characteristic parameters include a module ID, version information, and the dependency relationship; Request events that drive the BIOS to work or change are monitored. The request events include target characteristic parameters. The target characteristic parameters include a target module ID, target version information, and target dependency relationship; If the target characteristic parameters do not match any of the characteristic parameters (the target characteristic parameters matching the characteristic parameters means that the information contained in the target characteristic parameters corresponds one by one to the information contained in the characteristic parameters), it is determined whether there is a module ID that matches the target module ID. If there is, the module corresponding to the module ID that is the same as the target ID is determined as the target module; The target module is driven to change based on the request event, and the characteristic parameters of the target module are correspondingly updated to the target characteristic parameters; If the target characteristic parameters do not match any of the characteristic parameters and there is no module ID that matches the target module ID, it is determined whether the type of the request event is to add a module. If so, a security check is performed on the request event. If the check passes, a corresponding functional module is added based on the request event; If the type of the request event is not to add a module, or the security check on the request event fails, the request event is ignored.

2. The event-driven BIOS security protection and recovery optimization method according to claim 1, characterized in that It further includes the following steps: If the target characteristic parameters do not match any of the characteristic parameters and there is no module ID that matches the target module ID, the request event is ignored.

3. The event-driven BIOS security protection and recovery optimization method according to claim 1, wherein It further includes the following steps: If the target characteristic parameters match the characteristic parameters, the module that matches is driven to work according to the request event.

4. The event-driven BIOS security protection and recovery optimization method according to claim 1, wherein It further includes the following steps: During the operation of the BIOS, logical snapshots corresponding to each module are regularly generated. The logical snapshots include characteristic parameters and operating states. The operating states include normal operation and abnormal operation; When the module is tampered with or there is an abnormality, a module recovery mechanism is triggered, including: Determining that the module version with a normal operating state in the logical snapshot is a trusted version; Replacing the current version of the module with the trusted version, and correspondingly updating the characteristic parameters of the module.

5. The event-driven BIOS security protection and recovery optimization method according to claim 4, wherein Replacing the current version of the module with the trusted version includes: Determining the abnormal data in the current version of the module by comparing the current version of the module with the trusted version; Overwriting the abnormal data with the corresponding data in the trusted version.

6. The event-driven BIOS security protection and recovery optimization method according to claim 1, wherein It further includes the following steps: During the operation of the BIOS, logical snapshots corresponding to each module are regularly generated. The logical snapshots include characteristic parameters and operating states. The operating states include normal operation and abnormal operation; Determine that the module version with the running status of normal operation as determined by the previous logical snapshot is a trusted version; For each module, after generating the latest logical snapshot, compare the latest logical snapshot with the logical snapshot corresponding to the most recent trusted version. If the comparison is consistent, determine that the current module is normal; otherwise, determine that the current module is a non-trusted module.

7. The method for optimizing BIOS security protection and recovery based on event-driven according to claim 6, characterized in that It further includes the following steps: For the non-trusted module, perform a security check on the module. If the check passes, determine that the non-trusted module is normal; otherwise, determine that the non-trusted module is abnormal, and use the trusted version to replace the current version of the non-trusted module, and accordingly update the characteristic parameters of the non-trusted module.

8. The event-driven BIOS security protection and recovery optimization method according to claim 4 or 6, characterized in that Generate the logical snapshot corresponding to the module regularly in the following manner: Create the corresponding initial logical snapshot based on the module of the initial version, and the initial logical snapshot includes the characteristic parameters, running status, and code; Adopt the incremental logical snapshot method to regularly generate the logical snapshot corresponding to the module, including recording the parts that have changed compared to the logical snapshot of the previous version, including the changed characteristic parameters, running status, and code.

9. The method for optimizing event-driven BIOS security protection and recovery according to claim 4 or 6, 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, load the trusted version corresponding to the module to be recovered from the NVRAM area, and use the trusted version to overwrite the current version of the module.

10. The event-driven BIOS security protection and recovery optimization method according to claim 4 or 6, characterized in that The module includes a hardware initialization module, a device driver module, and a monitoring module. Among them, the dependency relationship of the device driver module is that it depends on the hardware initialization module to execute first, and the dependency relationship of the monitoring module is that it depends on the device driver module to execute first; Among them, the monitoring module is configured to monitor the running status and change situation of other modules to generate the logical snapshot corresponding to the module, and the logical snapshot includes characteristic parameters and running status.

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

12. A computer system, characterized in that, The computer system includes the BIOS system described in claim 11.

Images