BIOS firmware security verification method based on trusted execution environment

Abstract

The invention discloses a BIOS firmware security verification method and system based on a trusted execution environment, and belongs to the technical field of computer security, the BIOS firmware security verification method comprises the following steps: obtaining a complete mirror image, a key configuration variable and a system management mode code snippet of BIOS firmware, and processing data in the trusted execution environment to generate a trusted baseline snapshot; monitoring a high-risk system event, and triggering the verification of the running state of the BIOS according to the high-risk system event; reading data in the current memory and comparing the data with the trusted baseline snapshot to generate a tampering detection result and abnormal behavior judgment; and executing hierarchical response according to the threat level, and executing a hot repair operation for a high threat event. According to the method, the trusted execution environment is adopted to realize monitoring and active repair during operation, malicious tampering in the memory can be found and repaired immediately, and the safety and reliability of BIOS firmware during operation of an operating system are improved.

Description

Technical Field

[0001] This invention belongs to the field of computer security technology, and in particular relates to a BIOS firmware security verification method based on a trusted execution environment. Background Technology

[0002] The Basic Input / Output System (BIOS) or its modern alternative, the Unified Extensible Firmware Interface (UEFI), is the low-level software in a computer system responsible for hardware initialization, self-test, and booting the operating system. Running beneath all operating systems and applications, it possesses extremely high execution privileges. Due to its fundamental role, the security of the BIOS firmware directly impacts the trust foundation of the entire computing platform. Trusted Execution Environment (TEE), as a hardware-based security technology, creates an isolated, protected operating area within the main processor, providing confidentiality and integrity guarantees for sensitive computations and data storage. System Management Mode (SMM) is a highest-privilege execution mode provided by the processor, commonly used for low-level system management tasks, but it has also become a target for advanced persistent threat (APS) attackers.

[0003] Currently, security technologies for BIOS firmware primarily rely on verification mechanisms during the boot phase. For example, Secure Boot technology verifies the digital signatures of each firmware component during the boot process to ensure the loaded firmware and operating system bootloader are trustworthy, thus preventing the implantation of malicious bootloaders. Furthermore, some solutions utilize Trusted Platform Modules (TPMs) to measure critical components during the boot process and securely store the measurement values ​​for subsequent remote verification; this process is known as Trusted Boot or Metric Boot. Other host security software attempts to periodically scan and compare the firmware image file stored in the flash memory chip after the operating system has run.

[0004] However, existing technical solutions have significant limitations. First, the protective effect of mechanisms such as Secure Boot is mainly concentrated in the brief boot phase from system power-on self-test to operating system loading. Once the system is running normally, it cannot effectively monitor subsequent changes in the firmware's runtime state. Second, these technologies primarily focus on the static integrity of the firmware image in the storage medium. They lack effective detection methods for dynamic tampering by attackers directly modifying critical BIOS configuration data in memory or SMM code loaded into system management memory during system operation. Finally, when integrity breaches are detected, existing responses typically involve aborting the boot process or requiring manual intervention for offline repair. They lack the ability to perform real-time, automated repairs without affecting continuous system operation, directly leading to business interruptions and reduced system availability. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a BIOS firmware security verification method based on a trusted execution environment. This method establishes a dynamic trusted baseline within the trusted execution environment and combines event-driven verification, behavioral analysis, and a collaborative mechanism of memory-level hot repair. This enables continuous monitoring and proactive self-healing of the BIOS firmware's runtime state, enhancing the security and resilience of the system firmware without interrupting business operations.

[0006] The above objectives can be achieved through the following approach: A BIOS firmware security verification method based on a trusted execution environment includes: acquiring a complete image of the BIOS firmware, key configuration variables, and system management mode code snippets; processing the complete image, key configuration variables, and system management mode code snippets in the trusted execution environment to generate a trusted baseline snapshot; monitoring high-risk system events and triggering verification of the BIOS runtime state based on the occurrence of the high-risk system events; reading the key configuration variables and system management mode code in the current memory and comparing them with the trusted baseline snapshot to generate runtime tampering detection results; monitoring the behavior of the system management mode handler and comparing it with a pre-stored behavior baseline to generate an abnormal behavior judgment; when receiving the runtime tampering detection results and abnormal behavior judgment, performing a graded response according to the threat level, and performing a hotfix for high-threat events; if the hotfix is ​​frequently triggered within a specific time or the complete image of the BIOS firmware is detected to have been tampered with, triggering a system restart and entering the BIOS recovery process. Optionally, generating a trusted baseline snapshot includes: parsing the BIOS firmware to identify the specific content and location information of key configuration variables and system management mode code snippets; performing measurement calculations on the key configuration variables and system management mode code snippets to generate measurement data; and encrypting and aggregating the measurement data with a complete image of the BIOS firmware to generate a trusted baseline snapshot and storing it in protected memory of a trusted execution environment. Optionally, monitoring high-risk system events includes: establishing monitoring points for system management mode entry and exit events, power state transition events, and high-privilege ACPI method call events to obtain real-time event streams; receiving on-demand verification instructions from a remote management platform and integrating the on-demand verification instructions into the real-time event stream; analyzing the real-time event stream, and generating a verification trigger signal when any high-risk system event is identified.

[0007] Optionally, generating runtime tampering detection results includes: reading key configuration variables in the current memory and comparing them with corresponding variables in the trusted baseline snapshot to generate configuration variable comparison results; dynamically measuring the system management mode code in the current system management memory and verifying it with the corresponding records in the trusted baseline snapshot to generate code integrity verification results; and aggregating the configuration variable comparison results and code integrity verification results to generate runtime tampering detection results.

[0008] Optionally, the generation of abnormal behavior determination includes: recording the normal execution duration and memory access range of the system management mode handler in a trusted environment to establish a behavior baseline; capturing the current execution duration and memory access range in real time each time the system management mode handler is executed to form real-time behavior data; comparing and analyzing the real-time behavior data with the behavior baseline, and generating an abnormal behavior determination when a behavior deviation is detected. Optionally, when the runtime tampering detection result and abnormal behavior determination are received, a graded response is executed according to the threat level. For high-threat events, hot repair is performed including: assessing the threat level based on the runtime tampering detection result and the content of the abnormal behavior determination to generate a threat level determination; if the threat level determination is low threat, recording the event log and reporting it to the remote management platform through a secure channel; if the threat level determination is high threat, initiating a hot repair operation.

[0009] Optionally, the hot-repair operation includes: identifying the specific location of the tampered data in memory based on the runtime tampering detection results; retrieving the correct data segment corresponding to the specific location from the trusted baseline snapshot; and using the hardware isolation capability of the trusted execution environment to write the correct data segment to the specific location in an atomic operation manner to complete the hot-repair operation. Optionally, triggering the system restart and entering the BIOS recovery process includes: monitoring the triggering frequency of the hot-repair operation and generating a persistent attack judgment when the triggering frequency exceeds a threshold; verifying the complete image of the BIOS firmware in the storage medium and generating an image tampering alarm when the verification fails; triggering a network isolation mechanism and sending a secure restart command when the persistent attack judgment and image tampering alarm are received, guiding the system into the BIOS recovery process. Optionally, the method further includes: receiving a configuration update command from a remote management platform through the secure channel of the trusted execution environment; parsing the configuration update command and dynamically adjusting the definitions of the trusted baseline snapshot and high-risk system events based on the parsing results to generate an updated protection strategy; and reporting the logs of the runtime tampering detection results, the abnormal behavior judgment, and the response actions to the remote management platform through the secure channel for centralized security analysis.

[0010] Based on the same inventive concept, this invention also provides a BIOS firmware security verification system based on a trusted execution environment. The system includes: a baseline generation module, used to acquire a complete image of the BIOS firmware, key configuration variables, and system management mode code snippets, and process these in the trusted execution environment to generate a trusted baseline snapshot; an event-driven module, used to monitor high-risk system events and trigger verification of the BIOS runtime state based on the occurrence of the high-risk system events; a deep verification module, used to read key configuration variables and system management mode code currently in memory, compare them with the trusted baseline snapshot, generate runtime tampering detection results, monitor the behavior of the system management mode handler, and compare it with a pre-stored behavior baseline to generate an abnormal behavior judgment; a response decision module, used to execute a graded response based on the threat level when the runtime tampering detection results and abnormal behavior judgment are received, and to perform a hotfix for high-threat events; and an upgrade recovery module, used to trigger a system restart and enter the BIOS recovery process if the hotfix is ​​frequently triggered within a specific time period or if the complete image of the BIOS firmware is detected to have been tampered with.

[0011] Compared with the prior art, the present invention has the following advantages: 1. This invention achieves continuous and accurate monitoring of the runtime state of BIOS firmware by establishing a trusted baseline snapshot containing dynamic configurations and code snippets in a trusted execution environment and combining it with an event-driven verification mechanism. Compared to traditional static verification performed only during the startup phase, this method can capture and identify memory-level tampering and abnormal behavior attacks occurring during runtime in real time, greatly expanding the temporal dimension of security protection and the depth of threat detection, and improving the ability to detect advanced and covert attacks.

[0012] 2. This invention proposes a memory-level hot-repair self-healing mechanism. When high-threat tampering is detected, it leverages the hardware isolation advantages of a trusted execution environment to instantly restore tampered memory data using atomic operations. The entire process requires no system restart and is completely transparent to upper-layer services. This design fundamentally changes the traditional security response model that relies on system interruption or restart for recovery, ensuring business continuity and high availability. It is of great value to critical information infrastructure requiring uninterrupted operation.

[0013] 3. This invention constructs a complete closed-loop defense system, encompassing real-time monitoring, in-depth analysis, tiered response, and escalation recovery. This system intelligently differentiates threat levels, recording and reporting low-threat events only, performing instantaneous repairs on high-threat events, and automatically escalating persistent or root-cause attacks to thorough eradication measures such as network isolation and firmware reflashing. This flexible and in-depth response strategy provides strong self-recovery capabilities and security resilience, effectively addressing complex and ever-changing attack scenarios.

[0014] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a BIOS firmware security verification method based on a trusted execution environment according to an embodiment of the present invention.

[0017] Figure 2 This is a schematic diagram of the structure of a BIOS firmware security verification system based on a trusted execution environment according to an embodiment of the present invention.

[0018] Figure 3 This is a response delay curve of a key BIOS variable in an embodiment of the present invention.

[0019] Figure 4 This is a parallel coordinate comparison diagram of the protection capabilities of embodiments of the present invention and traditional security solutions. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Reference Figure 1One embodiment of the present invention proposes a BIOS firmware security verification method based on a trusted execution environment. It adopts a technical solution of constructing a trusted baseline snapshot, performing runtime dynamic comparison and behavior monitoring, and performing hot repair and self-healing based on graded response. This method can achieve continuous security verification and proactive defense of BIOS firmware, thereby improving the underlying security and reliability of computer systems.

[0022] The method described in this embodiment specifically includes: Obtain the complete image of the BIOS firmware, key configuration variables, and system management mode code snippets, and process the complete image, key configuration variables, and system management mode code snippets in a trusted execution environment to generate a trusted baseline snapshot; Monitor high-risk system events and trigger verification of the BIOS runtime state based on the occurrence of such high-risk system events; Read the key configuration variables and system management mode code in the current memory, compare them with the trusted baseline snapshot, and generate runtime tampering detection results; The monitoring system's management mode processes the behavior of the program and compares it with a pre-stored behavior baseline to generate an abnormal behavior judgment. Upon receiving the runtime tampering detection results and abnormal behavior determination, a graded response is executed according to the threat level. For high-threat events, hotfix is ​​performed. If the hotfix is ​​frequently triggered within a specific time period or if the complete image of the BIOS firmware is detected to have been tampered with, the system will be restarted and enter the BIOS recovery process.

[0023] Specifically, leveraging the hardware-enforced isolation features of a Trusted Execution Environment (TEE), an immutable trusted baseline snapshot containing a static firmware image, dynamic critical configurations, and core code snippets is created at the initial startup stage. During runtime, traditional periodic scanning is abandoned, replaced by a real-time verification mechanism driven by high-risk events such as System Management Mode (SMM) transitions and power state changes. The verification process goes beyond static code comparison, innovatively introducing monitoring and analysis of dynamic behaviors such as SMM code execution duration and memory access range to identify logical-level attacks. When tampering or abnormal behavior is detected, a tiered response is executed based on a pre-defined threat level model. For high-risk threats, the trusted baseline snapshot stored in the TEE is used to perform "hot repair" of tampered data in memory using atomic operations, achieving runtime self-healing. If the attack persists or the firmware source files are tampered with, an upgrade response, including network isolation and forced security recovery, is triggered, forming a complete security closed loop from real-time monitoring and in-depth analysis to instantaneous self-healing and thorough recovery.

[0024] Optionally, generating a trusted baseline snapshot includes: Analyze the BIOS firmware to identify the specific content and location information of key configuration variables and system management mode code snippets; The key configuration variables and system management mode code snippets are measured and calculated to generate measurement data; The metric data is cryptographically aggregated with a complete image of the BIOS firmware to generate a trusted baseline snapshot, which is then stored in protected memory within a trusted execution environment.

[0025] Specifically, during the cold boot phase, a secure application pre-loaded into the Trusted Execution Environment (TEE) is executed. The TEE is a hardware-isolated CPU runtime environment where the code and data are protected by hardware and cannot be accessed by external conventional operating systems or malware. The secure application parses the BIOS firmware stored in the SPI flash memory chip, a non-volatile memory on the motherboard used to store firmware. The parsing process follows the Unified Extensible Firmware Interface (UEFI) standard, traversing the firmware file system and data structures to locate the NVRAM region storing key configuration variables and identify preset key configuration variables, such as the Secure Boot switch and boot device sequence. Simultaneously, the secure application parses system description tables such as the Advanced Configuration and Power Interface (ACPI) table to obtain the entry address of the System Management Mode (SMM) and further locates the various system management mode (SMRAM) handler codes within the system management memory. System management mode is a highest-privilege execution mode of the processor, commonly used to execute low-level system management tasks. The security application uses a secure hash algorithm, such as SHA-256, to calculate a set of digital fingerprints for each identified key configuration variable and system management mode code snippet, generating the measurement data. This calculation process can be represented as M equals H(D), where M represents the generated measurement data, H represents the secure hash function, and D represents the data content of the key configuration variables or system management mode code snippets. The security application aggregates all the generated measurement data with the image measurement value obtained by hashing the complete image of the entire BIOS firmware, encrypts it using a hardware key accessible only within the Trusted Execution Environment (TEE), forming an encrypted data packet. This data packet is the trusted baseline snapshot, which is securely cached in the protected memory of the TEE, providing an immutable reference standard for subsequent runtime verification.

[0026] Optionally, the monitoring of high-risk system events includes: Establish monitoring points for system management mode entry and exit events, power state transition events, and high-privilege ACPI method call events to obtain real-time event streams; Receive on-demand verification instructions from the remote management platform and integrate the on-demand verification instructions into the real-time event stream; Analyze the real-time event stream and generate a verification trigger signal when any high-risk system event is identified.

[0027] Specifically, an event-driven triggering mechanism is established by a security application running within the Trusted Execution Environment (TEE) to achieve efficient real-time verification of the BIOS runtime state. This mechanism does not employ fixed periodic polling but instead presets and listens for a series of high-risk system events. The first triggering condition is the entry and exit of System Management Mode (SMM). The security application monitors the occurrence of System Management Interrupts (SMIs) by setting hook programs in the firmware. Whenever the system is about to enter or exit SMM due to an SMI, the hook program initiates a call to the TEE via a secure processor instruction, notifying the security application of this event. The second triggering condition is power state transition events, specifically referring to the process of the system waking up from hibernation S3 or S4. The ACPI (Advanced Configuration and Power Interface) defines these power states. Hooks are also embedded in the ACPI wake-up code path in the firmware to ensure that the security application in the TEE is notified before system control is returned to the operating system. The third triggering condition is the invocation of high-privilege ACPI methods. In the BIOS firmware, a set of high-risk ACPI methods that may modify the underlying hardware state or security policies are pre-identified and marked. The ACPI interpreter in the firmware has been modified to trigger a notification to the security application before executing these marked methods. The fourth trigger is receiving an on-demand verification command from a remote security management platform. This is implemented through a trusted proxy at the operating system level, which receives the command via a secure encrypted channel, verifies its legitimacy, and then forwards the verification request to the security application in the trusted execution environment via a dedicated driver interface. The security application continuously listens for event notifications from these four sources, and when any trigger condition is met, the application is immediately activated and initiates the subsequent verification process.

[0028] Optionally, the generation of runtime tampering detection results includes: Read the key configuration variables in the current memory and compare them with the corresponding variables in the trusted baseline snapshot to generate configuration variable comparison results; The system management mode code in the current system management memory is dynamically measured and verified against the corresponding record in the trusted baseline snapshot to generate a code integrity verification result. The configuration variable comparison results and code integrity verification results are aggregated to generate runtime tampering detection results.

[0029] Specifically, when a verification process is triggered based on a high-risk system event, the security application running in the Trusted Execution Environment (TEE) performs a two-dimensional deep verification process. For the verification of critical BIOS configuration variables, the security application directly accesses the Non-Volatile Random Access Memory (NVRAM) region mapped in the current system memory. Based on the variable addresses and sizes recorded in the Trusted Baseline Snapshot, it reads the real-time values ​​of each currently active critical configuration variable and compares them byte-by-byte with the corresponding gold standard values ​​cached in the Trusted Baseline Snapshot. If all variable values ​​are completely consistent, a configuration variable comparison result indicating normal configuration is generated; if any mismatch is found, a configuration variable comparison result indicating tampering is generated, and the specific mismatched variable is recorded. For the verification of System Management Mode (SMM) code, the security application accesses the System Management Memory (SMRAM), a memory region that is strictly protected under normal conditions. The security application reads the binary data of the code of the SMM handler that is about to be executed or currently resident and dynamically measures it using the same secure hash algorithm, such as SHA-256, used when generating the Trusted Baseline Snapshot, generating a real-time hash value. This process can be represented as H_runtime equals H, where H_runtime represents the hash value calculated in real time, H represents the secure hash function, and C_runtime represents the SMM code content read from SMRAM. This real-time hash value is compared with the original hash value of the corresponding code stored in the trusted baseline snapshot. If they match, a code integrity check result indicating that the code is intact is generated; otherwise, a code integrity check result indicating that the code has been modified is generated. The security application logically aggregates the outputs of the above two checks, namely the configuration variable comparison result and the code integrity check result. Only when both results are normal will the final runtime tampering detection result be "no tampering detected"; if either check fails, a runtime tampering detection result with the content "tampering detected" will be generated, and this result will be used as input for the subsequent response phase.

[0030] Optionally, the determination of abnormal behavior includes: Record the normal execution time and memory access range of the system management mode handler in a trusted environment to establish a behavioral baseline; Each time the system management mode handler is executed, it captures the current execution time and memory access range in real time to form real-time behavioral data; The real-time behavior data is compared and analyzed with the behavior baseline. When a deviation from the behavior is detected, an abnormal behavior judgment is generated.

[0031] Specifically, building upon static code integrity verification, monitoring and analysis of the dynamic execution behavior of System Management Mode (SMM) handlers are introduced. During the initial deployment phase or within a trusted execution environment (TEE), security applications within the TEE enter a learning and profiling phase to establish behavioral baselines. During this phase, for pre-identified critical SMM handlers, the security application uses the processor's high-precision timestamp counter to record the execution time from entering to exiting SMM during multiple normal executions. This time data is then statistically analyzed to determine a normal execution time upper limit threshold for each handler. Simultaneously, the address ranges of System Management Memory (SMRAM) and other memory regions accessed by the SMM handlers during execution are analyzed to clarify their legal read / write boundaries. These statistically derived execution time thresholds and legal memory access ranges are organized into a data structure—the behavioral baseline—and securely stored in the protected memory of the TEE. During normal operation, whenever a system management mode event is triggered and the corresponding SMM handler is invoked, the security application intervenes in real time. The actual execution time of this call will be measured again using a high-precision timestamp counter, and the memory addresses attempted to be accessed during its execution will be monitored. Then, the security application performs a comparison operation, comparing the real-time captured execution time with the corresponding upper limit threshold in the behavioral baseline. This comparison can be expressed as: ; in, This refers to the actual execution time of this measurement. This is the upper limit threshold for the execution time stored in the behavior baseline. Simultaneously, it checks whether all accessed memory addresses fall within the legal range defined by the behavior baseline. If the execution time significantly exceeds the threshold, or if any attempt is made to access memory outside the baseline range, the security application will determine this execution as abnormal and immediately generate an abnormal behavior judgment, which will serve as input to trigger subsequent response mechanisms.

[0032] Optionally, when the runtime tampering detection result and abnormal behavior determination are received, a graded response is performed according to the threat level. For high-threat events, hotfix is ​​performed, including: Based on the runtime tampering detection results and the content of the abnormal behavior determination, a threat level assessment is performed, and a threat level determination is generated. If the threat level is determined to be low threat, the event log is recorded and reported to the remote management platform through a secure channel; If the threat level is determined to be high, a hotfix operation will be initiated.

[0033] Specifically, upon receiving the generated runtime tampering detection results or abnormal behavior determination, the security application within the Trusted Execution Environment (TEE) immediately initiates a tiered response process. This process categorizes the received alarm information based on a predefined threat level model, thereby generating a threat level assessment. This model is a set of predefined rules that maps different types of tampering or abnormal behavior to different threat levels. For example, modifying a non-critical configuration variable is defined as a low-threat event, while disabling the Secure Start switch, compromising the integrity of the System Management Mode (SMM) code, or exhibiting severe behavioral anomalies in the SMM handler are explicitly defined as high-threat events. For low-threat events, the security application performs logging and reporting operations. A detailed log containing a timestamp, event type, and relevant context data is generated and securely stored in a non-volatile storage area managed by the TEE. Simultaneously, the alarm information is sent to a remote management platform via an encrypted secure channel for subsequent auditing and analysis by the security administrator; business operations are not interrupted during this process. Conversely, if the threat level assessment indicates a high-threat event, the security application triggers a memory-level hotfix operation. First, the precise physical address of the tampered critical configuration variable or SMM code in system memory is located. Then, a corresponding original and correct "golden" data copy is extracted from a trusted baseline snapshot stored in the TEE's protected memory. Finally, leveraging the hardware-level isolation and high-privilege advantages provided by the TEE, the secure application directly performs a write operation on the target memory address, atomically overwriting the tampered content with the correct "golden" data. This atomic operation ensures the indivisibility and uninterrupted nature of the write process, thus eliminating the possibility of interference from malicious code during the repair process. The entire hot-repair operation is completed without the operating system's awareness.

[0034] Optionally, the hotfix initiation operation includes: Based on the runtime tampering detection results, identify the specific location of the tampered data in memory; Retrieve the correct data segment corresponding to the specific location from the trusted baseline snapshot; By leveraging the hardware isolation capabilities of the Trusted Execution Environment, atomic operations are used to write the correct data fragments to a specific location, thus completing the hot-repair operation.

[0035] Specifically, when a high-threat event triggers a hotfix operation, the security application running within the Trusted Execution Environment (TEE) executes a series of precise and high-speed memory write processes. The first step is precise identification of the tampered location. During previous verification, when inconsistencies are found, the security application not only generates runtime tamper detection results but also records the names of mismatched critical configuration variables or the identifier of the tampered System Management Mode (SMM) code segment. At this point, the security application uses this information to query an internally maintained address mapping table, which is generated synchronously during the initialization of the Trusted Baseline Snapshot and records the accurate address and length of each critical data item in the current system's physical memory. Through this query, the security application obtains the starting physical address and data size of the tampered location in memory. The second step is to retrieve the correct data fragment from the Trusted Baseline Snapshot. Using the identifier of the tampered location as an index, the security application searches within the Trusted Baseline Snapshot cached in its protected memory, securely decrypting and extracting the corresponding original and untampered data content to form the correct data fragment. The third step is to execute a high-privilege atomic write operation. Leveraging the hardware isolation provided by a Trusted Execution Environment (TEE), secure applications can bypass the operating system's memory management and protection mechanisms, directly initiating write commands to physical memory addresses. It treats the retrieved correct data fragments as a single block and writes them all at once to the tampered location identified in the first step, using specific processor instructions. This write operation is designed to be atomic, meaning it cannot be interrupted by any interrupts or other processor core activities; it is an indivisible unit from start to finish, ensuring the integrity and consistency of the restoration process. The entire process, from identification and retrieval to writing, is completed at extremely high speeds at the hardware level, typically within nanosecond to microsecond timescales, achieving instantaneous restoration of the memory state.

[0036] Optionally, triggering the system restart and entering the BIOS recovery process includes: Monitor the triggering frequency of the hotfix operation, and generate a continuous attack determination when the triggering frequency exceeds a threshold; Verify the complete image of the BIOS firmware in the storage medium, and generate an image tampering alarm if the verification fails; Upon receiving the persistent attack determination and image tampering alarm, the network isolation mechanism is triggered and a secure reboot command is sent to guide the system into the BIOS recovery process.

[0037] Specifically, an upgrade response mechanism has been established to address persistent or root-cause threats that cannot be eradicated by memory-level hotfix operations. To combat persistent attacks, the security application within the Trusted Execution Environment (TEE) incorporates a counter and timer to monitor the trigger frequency of hotfix operations. Each successful hotfix increments the counter. The timer cycles through a preset time window, such as one minute. If the counter value exceeds a preset threshold within a single window, such as three times, the security application determines that the system is under persistent attack, and memory-based hotfixes alone are insufficient. In this case, it generates a persistent attack determination. To address root-cause threats, the security application periodically, or after each hotfix operation, performs an integrity check on the original BIOS firmware image stored in the SPI flash memory chip. It reads the firmware image from the SPI flash memory and calculates its hash value using the same secure hash algorithm used when generating the trusted baseline snapshot. This real-time hash value is then compared to the hash value of the original image stored in the trusted baseline snapshot. If an inconsistency is found, it indicates that the firmware's static storage medium has been tampered with offline, a more serious root-cause threat than memory tampering. At this point, the security application generates an image tampering alert. Once a persistent attack is detected or an image tampering alert is generated, the security application immediately triggers an escalation response. It sends a signal containing a reboot command to a trusted agent at the operating system level through a pre-defined security interface. Simultaneously, it immediately initiates a network isolation mechanism by configuring the network interface controller, such as modifying firewall rules or disabling network ports, cutting off all connections between the host and the external network to prevent potential lateral spread of malware. After issuing the reboot command, the security application sets a special hardware flag, which is read by the BIOS's early boot code after the system reboots. The BIOS, upon reading this flag, skips the regular boot process and forces entry into a dedicated, integrity-verified BIOS recovery process. This process loads a trusted firmware image from a protected backup area and performs a complete re-flash of the SPI flash memory chip.

[0038] Optionally, the method further includes: Receive configuration update commands from the remote management platform through the secure channel of the trusted execution environment; The configuration update command is parsed, and the definitions of the trusted baseline snapshot and high-risk system events are dynamically adjusted based on the parsing results to generate an updated protection strategy; The logs of runtime tampering detection results, abnormal behavior judgments, and response actions are reported to the remote management platform through a secure channel for centralized security analysis.

[0039] Specifically, it includes a closed-loop interaction mechanism with the remote management platform to achieve dynamic policy updates and centralized awareness of security posture. To enable policy updates, a trusted agent is deployed at the operating system level. This agent establishes a persistent, two-way encrypted communication link with the remote management platform via the standard Transport Layer Security (TLS) protocol; this is the secure channel of the Trusted Execution Environment (TEE). Security administrators on the remote management platform can issue configuration update commands based on newly discovered threat intelligence or changing business security needs. These commands are digitally signed to ensure their authenticity and integrity. Upon receiving a command, the trusted agent first verifies its signature. After successful verification, it securely transmits the command content to the security application within the TEE via a dedicated driver interface. The security application, upon receiving the configuration update command, parses its content. For example, the command might require adding a new System Management Mode (SMM) handler to the monitoring system or adjusting the trigger threshold for a high-risk system event. The security application dynamically modifies its internal configuration parameters based on the command and regenerates or updates parts of the trusted baseline snapshot, ensuring its protection policies remain up-to-date. To achieve centralized awareness of security posture, security applications within the TEE encapsulate all their security activity logs in real time, including the initiation of each verification, the generation of runtime tampering detection results, anomaly judgments, and executed response actions. This encapsulated log data is then transmitted via a reverse secure channel—from the TEE to a trusted agent—which in turn reports it to the remote management platform in real time through an encrypted link. Upon receiving this massive amount of security data from different hosts, the remote management platform can perform centralized storage, correlation analysis, and visualization, thereby providing the security team with a global, real-time view of the firmware security posture.

[0040] Based on the same inventive concept, such as Figure 2 As shown, the present invention also provides a BIOS firmware security verification system based on a trusted execution environment, the system comprising: The baseline generation module is used to obtain the complete image of the BIOS firmware, key configuration variables, and system management mode code snippets, and process the complete image, key configuration variables, and system management mode code snippets in a trusted execution environment to generate a trusted baseline snapshot. An event-driven module is used to monitor high-risk system events and trigger verification of the BIOS runtime state based on the occurrence of such high-risk system events. The deep verification module is used to read key configuration variables and system management mode code in the current memory, compare them with the trusted baseline snapshot, generate runtime tampering detection results, monitor the behavior of the system management mode handler, and compare it with the pre-stored behavior baseline to generate abnormal behavior judgments. The response decision module is used to perform a graded response based on the threat level when it receives the runtime tampering detection result and abnormal behavior judgment. For high-threat events, it performs hot repair. The upgrade recovery module is used to trigger a system restart and enter the BIOS recovery process if the hotfix is ​​frequently triggered within a specific time period or if the complete image of the BIOS firmware is detected to have been tampered with.

[0041] To verify the beneficial effects of this invention, two typical attack scenarios were simulated, and the responses of the system were recorded. Scenario 1: An attacker exploits an operating system kernel vulnerability to tamper with the "Boot Device Order" variable in memory, attempting to force the server to boot from a malicious USB drive next time. Scenario 2: An attacker injects malicious code into a legitimate SMM (System-Modified Memory) handler via a DMA (Distributed Access Memory) attack. This code, without altering the original program's functionality, performs additional operations to steal sensitive memory data, resulting in a slight increase in the handler's execution time.

[0042] In Scenario 1, the verification process is triggered when the system enters SMM due to a normal event. The configuration variable comparison immediately detects a discrepancy between the "Boot Device Order" variable and the trusted baseline. The system assesses this event as a high-threat event and immediately initiates a memory-level hotfix. The security application extracts the correct boot order data from the trusted baseline snapshot and, through an atomic write operation, overwrites the tampered location in memory within 500 nanoseconds. The entire process is completely transparent to the upper-layer operating system and business applications, and server operations are unaffected.

[0043] In Scenario 2, the hash value of the SMM code may not have changed, but the behavior monitoring module detects that the execution time of the SMM handler is 15 microseconds longer than the threshold in the behavior baseline. Based on this, the system generates an abnormal behavior judgment, also assessing it as a high-threat event, and triggers logging and an alert to the remote management platform. If the attacker further modifies the code, causing the hash value to change, the code integrity verification will fail directly, triggering a hotfix that overwrites the corrupted memory area with the original SMM code snippet from the trusted baseline.

[0044] A persistent attack was also simulated. An attacker attempted to tamper with the "Secure Boot" switch every 10 seconds in a script. The invention detected the tampering three times consecutively and successfully executed a hotfix. After the third fix, the built-in counter exceeded the threshold of "triggered 3 times within 1 minute," indicating a persistent attack. An upgrade response was immediately triggered: first, the server's network connection was isolated by configuring the network interface controller; then, a secure reboot command was sent, and the hardware recovery flag was set. The system was then forced into the BIOS recovery process after reboot, performing a complete re-flash of the SPI flash memory from a protected backup area.

[0045] Data demonstrates that this invention offers significant advantages in firmware runtime security protection. Compared to traditional methods that can only detect problems at startup, this invention achieves real-time detection and response at runtime. Memory-level hotfix can instantly eliminate threats without interrupting services, ensuring 99.999% availability of critical services. The upgrade response mechanism provides ultimate security assurance against advanced persistent threats.

[0046] Figure 3 This figure shows the response latency curves of key BIOS variables in the method of this invention. It simulates the dynamic response of the system after a runtime memory tampering attack, comparing the recovery latency of the proposed solution and a conventional solution. The solid line represents the proposed solution, which can quickly converge the response latency to the baseline level after the attack occurs; the dashed line represents the conventional solution, whose response latency is in an unstable oscillating state, demonstrating the superior performance of the proposed solution in handling runtime threats.

[0047] Table 1 BIOS Firmware Runtime Verification and Response Data Table Table 2 Comparison of the effects of different protection schemes

[0048] Figure 4 This is a graph comparing the protection capabilities of the method in this invention with those of traditional security solutions. The graph quantifies the decision space of the hierarchical response mechanism of this invention. Contour lines represent different levels of response success rates, with the central "optimal response point" located at the intersection of high threat level and extremely short response latency.

[0049] As can be seen from the data in Tables 1 and 2 above, the method of this invention demonstrates outstanding capabilities in handling runtime threats. Table 1 details the system's precise response to different types of events, detecting and handling both tampering with configuration variables and abnormal behavior in SMM code within nanoseconds to milliseconds. Especially when facing persistent attacks, it can intelligently escalate from "hotfix" to "secure recovery," forming a closed-loop defense.

[0050] The comparative data in Table 2 clearly highlights the technical advantages of this invention. For various runtime attacks that traditional security solutions cannot cover, this invention not only achieves "real-time detection," but more importantly, it provides "instantaneous repair" capabilities with "uninterrupted business operations." This proactive and self-healing protection mechanism greatly enhances the system resilience and security of critical business servers, and its comprehensive protection effect far surpasses existing static or startup-time verification technologies.

[0051] It should be noted that the electrical connections between the various units described above do not necessarily represent direct or indirect connections. Any indirect connection method can be applied to the embodiments of the present invention as long as it achieves the purpose of the present invention. The above descriptions are merely exemplary embodiments of the present invention and should not be construed as limiting the scope of the present invention.

[0052] All equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of this invention upon considering the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this invention that follow the general principles of this invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A BIOS firmware security verification method based on a trusted execution environment, characterized in that, Includes the following steps: Obtain the complete image of the BIOS firmware, key configuration variables, and system management mode code snippets, and process the complete image, key configuration variables, and system management mode code snippets in a trusted execution environment to generate a trusted baseline snapshot; Monitor high-risk system events and trigger verification of the BIOS runtime state based on the occurrence of such high-risk system events; Read the key configuration variables and system management mode code in the current memory, compare them with the trusted baseline snapshot, and generate runtime tampering detection results; The monitoring system's management mode processes the behavior of the program and compares it with a pre-stored behavior baseline to generate an abnormal behavior judgment. Upon receiving the runtime tampering detection results and abnormal behavior determination, a graded response is executed according to the threat level. For high-threat events, hotfix is ​​performed. If the hotfix is ​​frequently triggered within a specific time period or if the complete image of the BIOS firmware is detected to have been tampered with, the system will be restarted and enter the BIOS recovery process.

2. The BIOS firmware security verification method based on a trusted execution environment as described in claim 1, characterized in that, The generation of trusted baseline snapshots includes: Analyze the BIOS firmware to identify the specific content and location information of key configuration variables and system management mode code snippets; The key configuration variables and system management mode code snippets are measured and calculated to generate measurement data; The metric data is cryptographically aggregated with a complete image of the BIOS firmware to generate a trusted baseline snapshot, which is then stored in protected memory within a trusted execution environment.

3. The BIOS firmware security verification method based on a trusted execution environment as described in claim 1, characterized in that, The high-risk system events being monitored include: Establish monitoring points for system management mode entry and exit events, power state transition events, and high-privilege ACPI method call events to obtain real-time event streams; Receive on-demand verification instructions from the remote management platform and integrate the on-demand verification instructions into the real-time event stream; Analyze the real-time event stream and generate a verification trigger signal when any high-risk system event is identified.

4. The BIOS firmware security verification method based on a trusted execution environment as described in claim 1, characterized in that, The generated runtime tampering detection results include: Read the key configuration variables in the current memory and compare them with the corresponding variables in the trusted baseline snapshot to generate configuration variable comparison results; The system management mode code in the current system management memory is dynamically measured and verified against the corresponding record in the trusted baseline snapshot to generate a code integrity verification result. The configuration variable comparison results and code integrity verification results are aggregated to generate runtime tampering detection results.

5. The BIOS firmware security verification method based on a trusted execution environment as described in claim 1, characterized in that, The determination of abnormal behavior includes: Record the normal execution time and memory access range of the system management mode handler in a trusted environment to establish a behavioral baseline; Each time the system management mode handler is executed, it captures the current execution time and memory access range in real time to form real-time behavioral data; The real-time behavior data is compared and analyzed with the behavior baseline. When a deviation from the behavior is detected, an abnormal behavior judgment is generated.

6. The BIOS firmware security verification method based on a trusted execution environment as described in claim 1, characterized in that, When the runtime tampering detection result and abnormal behavior determination are received, a graded response is executed according to the threat level. For high-threat events, hotfix is ​​performed, including: Based on the runtime tampering detection results and the content of the abnormal behavior determination, a threat level assessment is performed, and a threat level determination is generated. If the threat level is determined to be low threat, the event log is recorded and reported to the remote management platform through a secure channel; If the threat level is determined to be high, a hotfix operation will be initiated.

7. The BIOS firmware security verification method based on a trusted execution environment as described in claim 6, characterized in that, The hotfix initiation process includes: Based on the runtime tampering detection results, identify the specific location of the tampered data in memory; Retrieve the correct data segment corresponding to the specific location from the trusted baseline snapshot; By leveraging the hardware isolation capabilities of the Trusted Execution Environment, atomic operations are used to write the correct data fragments to a specific location, thus completing the hot-repair operation.

8. The BIOS firmware security verification method based on a trusted execution environment as described in claim 1, characterized in that, The process of triggering a system restart and entering the BIOS recovery includes: Monitor the triggering frequency of the hotfix operation, and generate a continuous attack determination when the triggering frequency exceeds a threshold; Verify the complete image of the BIOS firmware in the storage medium, and generate an image tampering alarm if the verification fails; Upon receiving the persistent attack determination and image tampering alarm, the network isolation mechanism is triggered and a secure reboot command is sent to guide the system into the BIOS recovery process.

9. The BIOS firmware security verification method based on a trusted execution environment as described in claim 1, characterized in that, Also includes: Receive configuration update commands from the remote management platform through the secure channel of the trusted execution environment; The configuration update command is parsed, and the definitions of the trusted baseline snapshot and high-risk system events are dynamically adjusted based on the parsing results to generate an updated protection strategy; The logs of runtime tampering detection results, abnormal behavior judgments, and response actions are reported to the remote management platform through a secure channel for centralized security analysis.

10. A BIOS firmware security verification system based on a trusted execution environment, characterized in that, The system is used for a BIOS firmware security verification method based on a trusted execution environment as described in any one of claims 1-9, comprising: The baseline generation module is used to obtain the complete image of the BIOS firmware, key configuration variables, and system management mode code snippets, and process the complete image, key configuration variables, and system management mode code snippets in a trusted execution environment to generate a trusted baseline snapshot. An event-driven module is used to monitor high-risk system events and trigger verification of the BIOS runtime state based on the occurrence of such high-risk system events. The deep verification module is used to read key configuration variables and system management mode code in the current memory, compare them with the trusted baseline snapshot, generate runtime tampering detection results, monitor the behavior of the system management mode handler, and compare it with the pre-stored behavior baseline to generate abnormal behavior judgments. The response decision module is used to perform a graded response based on the threat level when it receives the runtime tampering detection result and abnormal behavior judgment. For high-threat events, it performs hot repair. The upgrade recovery module is used to trigger a system restart and enter the BIOS recovery process if the hotfix is ​​frequently triggered within a specific time period or if the complete image of the BIOS firmware is detected to have been tampered with.

Images