A firmware security hot updating method and electronic equipment

Abstract

The application discloses a firmware security hot updating method and electronic equipment, and relates to the technical field of computers.The application generates a differential patch file by comparing a target firmware image with a current firmware image, verifies the integrity and source of the patch, creates rollback credentials and performs firmware updating after verifying that the patch behavior is credible by using a shadow execution environment, verifies the behavior credibility and integrity of the patch file in the shadow execution environment, and avoids the influence of errors or malicious patches on system stability and security; the rollback mechanism ensures that the system state can be quickly restored when an exception occurs, the risk in the updating process is minimized, and non-susceptible recovery can be realized without restarting.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a firmware security hot updating method and electronic equipment. BACKGROUND

[0002] The OpenBMC firmware security hot updating technology refers to an online upgrading technology of non-interrupt service, verifiable, tamper-proof and rollback for a baseboard management controller (BMC) firmware based on an OpenBMC open source framework without affecting the normal operation of a server. In the field of file encryption, related technologies mostly rely on a trusted root in the starting phase to establish trust, but the hot updating occurs during the system operation, and the traditional security detection mechanism does not cover the loading and application process of the differential patch. Attackers can inject malicious patches in this blind area, causing the firmware to be silently tampered with. The existing hot updating commonly adopts a timing task or manual triggering, and does not consider the current actual load state of the baseboard management controller, causing the updating process to aggravate resource competition and causing a watchdog timeout or malfunction of the management function. SUMMARY

[0003] The present application provides a firmware security hot updating method and electronic equipment to at least solve the problem that the security detection mechanism does not cover the loading and application process of the differential patch in the related technology, resulting in the existence of the way of injecting malicious patches to achieve the silent tampering of the firmware.

[0004] The present application provides a firmware security hot updating method, comprising:

[0005] comparing a target firmware image with a current running firmware image to obtain a differential patch file;

[0006] verifying an integrity measurement value of the differential patch file and its source information, and jointly binding the integrity measurement value of the differential patch file and its source information to form a trust chain extension record;

[0007] loading the differential patch file in a hardware isolated shadow execution environment, and confirming whether the differential patch file is behaviorally trustworthy by comparing whether the response outputs of the same query service request in the main running environment and the shadow execution environment are consistent;

[0008] in response to the differential patch file confirming the behaviorally trustworthy, creating a transient snapshot of the current file system and extracting key state information to encapsulate as rollback credentials, and applying the differential patch file to the current file system of the main running environment to complete the firmware updating;

[0009] in response to detecting that the main running environment runs abnormally or is inconsistent with the trust chain extension record, rolling back the file system and restoring the key state according to the rollback credentials to realize the firmware rollback of the main running environment.

[0010] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described firmware secure hot update methods.

[0011] The target firmware image is compared with the currently running firmware image to obtain the differential patch file;

[0012] The integrity metric of the differential patch file and its source information are verified, and the integrity metric of the differential patch file and its source information are jointly bound to form a trust chain extended record;

[0013] The differential patch file is loaded in a hardware-isolated shadow execution environment. The reliability of the differential patch file is confirmed by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request.

[0014] In response to the confirmation that the differential patch file behavior is trustworthy, a snapshot of the current file system is created and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main operating environment to complete the firmware update.

[0015] In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment's firmware is rolled back based on the rollback credential and the critical state is restored.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described firmware secure hot update methods:

[0017] The target firmware image is compared with the currently running firmware image to obtain the differential patch file;

[0018] The integrity metric of the differential patch file and its source information are verified, and the integrity metric of the differential patch file and its source information are jointly bound to form a trust chain extended record;

[0019] The differential patch file is loaded in a hardware-isolated shadow execution environment. The reliability of the differential patch file is confirmed by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request.

[0020] In response to the confirmation that the differential patch file behavior is trustworthy, a snapshot of the current file system is created and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main operating environment to complete the firmware update.

[0021] In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment's firmware is rolled back based on the rollback credential and the critical state is restored.

[0022] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described firmware secure hot update methods:

[0023] The target firmware image is compared with the currently running firmware image to obtain the differential patch file;

[0024] The integrity metric of the differential patch file and its source information are verified, and the integrity metric of the differential patch file and its source information are jointly bound to form a trust chain extended record;

[0025] The differential patch file is loaded in a hardware-isolated shadow execution environment. The reliability of the differential patch file is confirmed by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request.

[0026] In response to the confirmation that the differential patch file behavior is trustworthy, a snapshot of the current file system is created and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main operating environment to complete the firmware update.

[0027] In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment's firmware is rolled back based on the rollback credential and the critical state is restored.

[0028] This application generates a differential patch file by comparing the target firmware image with the current firmware image, verifies the integrity and source of the patch, and creates a rollback certificate and performs a firmware update after verifying the trustworthiness of the patch behavior using a shadow execution environment. By verifying the trustworthiness and integrity of the patch file behavior in the shadow execution environment, the impact of erroneous or malicious patches on system stability and security is avoided. The rollback mechanism ensures that the system state can be quickly restored in the event of an anomaly, minimizing the risks during the update process and achieving seamless recovery without the need for a reboot. Attached Figure Description

[0029] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a diagram illustrating the application environment of a firmware secure hot update method in one embodiment of this application.

[0031] Figure 2 This is a flowchart illustrating a firmware secure hot update method in one embodiment of this application;

[0032] Figure 3 This is a structural block diagram of a firmware secure hot update device in one embodiment of this application;

[0033] Figure 4 This is an internal structural diagram of a computer device in one embodiment of this application. Detailed Implementation

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

[0035] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0036] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0037] The firmware secure hot update method provided in this application can be applied to, for example... Figure 1 In the application environment shown, terminal 102 and server 104 communicate via a network. Terminal 102 sends a target firmware image for firmware upgrade to server 104, enabling server 104 to perform firmware upgrade based on the target firmware image. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices, and server 104 can be a standalone server or a server cluster consisting of multiple servers.

[0038] like Figure 2 As shown, an embodiment of this application provides a firmware secure hot update method, including the following steps:

[0039] Step S1: Compare the target firmware image with the currently running firmware image to obtain the differential patch file;

[0040] Step S2: Verify the integrity metric of the differential patch file and its source information, and bind the integrity metric of the differential patch file and its source information together to form a trust chain extension record;

[0041] Step S3: Load the differential patch file in the hardware-isolated shadow execution environment. Confirm whether the differential patch file is trustworthy by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request.

[0042] Step S4: In response to the trustworthy behavior of the differential patch file confirmation, a momentary snapshot is created on the current file system and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main runtime environment to complete the firmware update.

[0043] Step S5: In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment firmware is rolled back based on the rollback credentials and the critical state is restored.

[0044] The system generates a differential patch file by comparing the target firmware image with the current firmware image, verifies the integrity and source of the patch, and creates a rollback certificate and performs a firmware update after verifying the trustworthiness of the patch behavior using a shadow execution environment. By verifying the trustworthiness and integrity of the patch file behavior in the shadow execution environment, the system avoids the impact of erroneous or malicious patches on system stability and security. The rollback mechanism ensures that the system state can be quickly restored in the event of an anomaly, minimizing the risks during the update process and enabling seamless recovery without the need for a reboot.

[0045] In this embodiment, comparing the target firmware image with the currently running firmware image to obtain the differential patch file includes:

[0046] The binary differential algorithm is used to compare the executable code segment, configuration data segment and file system layout of the target firmware image with the currently running firmware image block by block to identify the data areas that have changed in content or address.

[0047] Generate a differential description file containing the modified offset, original data length, and new data content based on the area data that has changed in content or address;

[0048] The differential description file is stored in a compressed encoding format to generate a differential patch file.

[0049] By employing a differential algorithm, only the changed portions are transmitted and stored, rather than the entire firmware image, significantly reducing storage and network transmission overhead. This method reduces update time and resource consumption, making the firmware update process more efficient, especially during large-scale device updates, saving valuable bandwidth and storage space. Furthermore, precise differential generation improves update accuracy, reducing potential risks caused by redundant or erroneous updates.

[0050] In this embodiment, verifying the integrity metric of the differential patch file and its source information, and jointly binding the integrity metric of the differential patch file and its source information to form a trust chain extension record includes:

[0051] The differential patch file is hashed to obtain an integrity metric, which is then written to the Platform Configuration Register (PCR register) in the Trusted Platform Module (TPM).

[0052] Extract the unique identifier of the signature subject from the digital signature of the differential patch file, and perform a hash operation on the unique identifier of the signature subject to obtain the hash digest value;

[0053] The extended trust chain record is determined based on the hash digest value and the current register value of the platform configuration register.

[0054] The combination of hash values ​​and digital signatures ensures that patch files have not been tampered with during transmission. Hash value calculations uniquely identify each patch file and effectively prevent malicious tampering. Combined with TPM (Trusted Platform Module), patch integrity metrics can be bound to system hardware status, achieving hardware-level trust verification. This enhances the system's trust in update patches, ensuring the traceability and tamper-proof nature of patch files.

[0055] In this embodiment, determining the extended trust chain record based on the hash digest value and the current register value of the platform configuration register includes:

[0056] Get the current register value after the integrity metric value is written to the platform configuration register;

[0057] Obtain the hash digest value that uniquely identifies the signature subject;

[0058] The current register value is updated by performing a bitwise XOR operation between the hash digest value and the current value of the platform configuration register, which is used to establish a joint binding relationship between integrity and source information, forming an extended trust chain record.

[0059] The current register value after the integrity metric is written to the platform configuration register is PCRcurrent, and the hash digest value of the unique identifier of the signature subject is H(SID). The updated register value PCRnew is calculated by PCRnew=PCRcurrent⊕H(SID) to form an extended trust chain record; where ⊕ represents bitwise XOR operation.

[0060] Specifically, by performing a bitwise XOR operation, the hash digest of the patch file is combined with the TPM register value to form an extended trust chain, which strengthens the binding and verification of the patch's integrity and origin information. This method enhances the security of the trust chain and, through hardware-level verification, avoids the risk of software-level tampering or forgery of patch files. By combining it with TPM, the platform's hardware protection mechanisms can be leveraged to further improve the security of the update process.

[0061] In this embodiment, loading the differential patch file in a hardware-isolated shadow execution environment and confirming the trustworthiness of the differential patch file by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query service request includes:

[0062] A shadow execution space, isolated from the main runtime environment, is constructed to form a shadow execution environment. Service modules updated by differential patch files are deployed within the shadow execution space.

[0063] When the main runtime environment receives a query request, it copies the query request to the shadow execution environment and triggers the same processing flow.

[0064] The response codes, return data structures, and abnormal status flags output by the main runtime environment and the shadow execution environment are compared field by field. If the results of multiple consecutive comparisons are completely consistent and the shadow execution environment does not crash or time out, the behavior of the differential patch file is determined to be trustworthy.

[0065] For example, when a query request like "Get Temperature Information" is received in the primary environment, the system simultaneously sends this request to the shadow environment. The primary environment returns: {temp: 45°C, status: OK}. The shadow environment also returns: {temp: 45°C, status: OK}. If the results are consistent after more than 10 repeated tests, and the shadow environment does not crash, the module's update behavior is deemed reliable, and the update can be officially applied.

[0066] By verifying the behavior of differential patch files in a shadow execution environment, the reliability of patches can be tested without affecting the main system. If the patch files behave consistently and without anomalies in the shadow environment, they can be considered to run safely in the main environment as well. This process effectively avoids applying risky patches to the real system, ensuring the reliability of firmware updates and the stability of the system.

[0067] In this embodiment, when comparing the response codes, return data structures, and exception status flags output by the main runtime environment and the shadow execution environment field by field, the expression used to determine the credibility of the differential patch file behavior is:

[0068] ;

[0069] In the formula, This represents the response output of the main runtime environment to the k-th query request. This represents the response output of the shadow execution environment to the k-th query request. This indicates whether an exception occurred during the execution of the k-th query request in the shadow execution environment; ∧ represents a logical AND operation. This condition is true if it is met for all query requests from k=1 to k=N. This indicates a comparison of whether the two responses on both sides of the equals sign are equal. This indicates a logical NOT operation, and Trusted (△F) indicates that the behavior of the differential patch file is trustworthy;

[0070] When N consecutive comparisons all meet the requirement of consistent response and no anomalies, the differential patch file is determined to have reliable behavior.

[0071] In the expression used to determine the trustworthiness of the differential patch file behavior, for each query request, a test is passed as long as the response is consistent and without anomalies; only when all N tests pass is the entire patch behavior deemed trustworthy. The first "=" indicates an assignment relationship: defining the calculation method of Trusted(ΔF). The following "=" is a comparison operation used to determine whether two response outputs are equal.

[0072] By repeatedly comparing the responses of the main runtime environment and the shadow execution environment, the impact of occasional errors or differences can be minimized, ensuring that the behavior of the patch file remains reliable after multiple tests. This multiple-comparison mechanism improves the reliability of verification and, through rigorous comparison with the shadow environment, ensures that the patch does not introduce unforeseen errors or vulnerabilities.

[0073] In this embodiment, before loading the differential patch file in the hardware-isolated shadow execution environment, the following steps are also included:

[0074] Collect the current system load and obtain a system updability score based on the load.

[0075] When the system updability score is greater than a preset threshold, a shadow execution space isolated from the main runtime environment is constructed to form a shadow execution environment.

[0076] By assessing the system's load status in real time, firmware updates are ensured to occur only when system resources are sufficient and the load is low, avoiding updates that could impact performance or cause malfunctions during peak system activity. This mechanism improves the timeliness and adaptability of system updates, ensuring that updates are performed at appropriate times and reducing risks during the update process.

[0077] In this embodiment, the current system load is collected, and the system updability score is obtained based on the operating load, including:

[0078] The system acquires in real time the number of pending requests in the current system's command queue, the scheduling cycle deviation rate of sensor sampling tasks, and the transmission frequency of data bus (D-Bus) messages per unit time to form load indicators.

[0079] The difference between each load index and the corresponding preset low load benchmark value is calculated, multiplied by the corresponding service criticality weight coefficient, and then summed. After linear normalization, it is mapped to the standard interval, and a comprehensive score representing whether the system is currently suitable for hot update is output as the system updateability score.

[0080] By monitoring multiple system load metrics in real time and calculating a comprehensive score, the system's suitability for firmware updates can be accurately determined. This dynamic scoring mechanism, based on actual system load and the weight of each service, avoids update failures caused by high load or temporary busy tasks, ensuring that the system executes update tasks under stable load and improving the success rate of the update process.

[0081] In this embodiment, the difference between each load index and its corresponding preset low load benchmark value is calculated, multiplied by the corresponding service criticality weight coefficient, and then summed. This summation is then mapped to a standard interval through linear normalization, outputting a comprehensive score characterizing whether the system is currently suitable for hot updates. This score serves as the system updateability score and includes:

[0082] Get the actual load value Li of the i-th service, and get the low load baseline value corresponding to the i-th service. Get the maximum load capacity of the i-th service. Obtain the weight coefficient wi of the i-th service in the system;

[0083] pass Calculate the normalized system updability score .

[0084] By comparing the system's load status with a preset benchmark value, the system can assess its load in real time, thereby determining whether it is ready to perform a hot update. This mechanism avoids updating under excessive load or system pressure, reducing firmware update failures or performance degradation due to insufficient resources, and enhancing the system's intelligent update management capabilities.

[0085] In this embodiment, creating a snapshot of the current file system, extracting key state information, encapsulating it into rollback credentials, and applying the differential patch file to the current file system of the main runtime environment to complete the firmware update includes:

[0086] The file system state is locked before firmware updates via copy-on-write mechanism;

[0087] Create a snapshot of the current root file system;

[0088] Extract the hash value of the current firmware executable file, the content summary of key configuration files in the system configuration directory, the sequence of instructions that have not yet been executed in the command queue, and the list of service object paths registered on the data bus to form key status information;

[0089] Encapsulate instantaneous snapshots and critical status information into rollback credentials and store them in a separate reserved area;

[0090] The updated content in the differential patch file is written to the current file system of the copy-on-write file system, triggering the relevant service process to reload the module that updates the differential patch file.

[0091] The copy-on-write mechanism ensures that update operations do not affect the current system state, thus avoiding potential risks during the update process. By creating a snapshot of the file system and extracting key state information, a complete rollback certificate is formed. If a problem occurs after a firmware update, the original state can be quickly restored through the rollback mechanism. This mechanism provides fast and reliable recovery capabilities, ensuring high availability of firmware updates.

[0092] In this embodiment, before applying the differential patch file to the current file system of the main runtime environment to complete the firmware update, the following steps are also included:

[0093] Perform content analysis on differential patch files to identify potential security vulnerabilities or known malicious code contained therein, and conduct security audits on differential patch files through virus scanning and behavioral analysis.

[0094] If malicious content is detected, the application of the differential patch file to the current file system of the main runtime environment will be stopped and a warning will be triggered.

[0095] By performing content analysis on the differential patch file before firmware updates, the security of the differential patch file can be guaranteed.

[0096] In this embodiment, when encapsulating the instantaneous snapshot and key state information into rollback credentials and storing them in a separate retention area, the method further includes:

[0097] The key status information in the rollback certificate is encrypted and stored using a public-key symmetric encryption algorithm, so that the key of the rollback certificate can be decrypted through a secure channel during the recovery process.

[0098] By encrypting the critical status information in the rollback credentials, tampering or leakage of the credentials during storage or transmission can be prevented, ensuring the security and reliability of the rollback process. The encryption mechanism enhances the confidentiality and integrity of the system, ensuring that the credentials can be decrypted through a secure channel during firmware rollback, thereby accurately restoring the system state.

[0099] In this embodiment, in response to detecting an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the firmware rollback of the main runtime environment is achieved by rolling back the file system and restoring the critical state based on the rollback credentials, including:

[0100] If a service crash is detected after a firmware update, the value of the platform configuration register (PCR register) cannot be verified by remote proof, or a critical task response times out, the current file system will be stopped.

[0101] The file system is rolled back to the instantaneous snapshot version before the update, and the queue state and data bus service registration information are restored according to the contents recorded in the rollback certificate, so as to achieve millisecond-level atomic rollback of firmware without restarting.

[0102] The types of runtime environment errors include:

[0103] Runtime exception (occurring in the main environment);

[0104] The main environment crashes (such as segfault, panic).

[0105] Critical services are unresponsive (e.g., IPMI command timeout > 5s);

[0106] D-Bus message loss or blockage;

[0107] Sensor data acquisition was interrupted;

[0108] The observed abnormal system behavior suggests that the new firmware may have introduced a fatal bug.

[0109] Inconsistencies with the trust chain extension record include:

[0110] Trust chain anomaly (security issue);

[0111] The TPM PCR register value cannot be verified remotely (i.e., the chain of trust is broken).

[0112] Digital signature verification failed (indicating the patch has been tampered with);

[0113] The differential patch source is invalid (SID mismatch).

[0114] The system utilizes a rollback mechanism to enable rapid system recovery after firmware updates, restoring it to a normal state without requiring a system reboot. This millisecond-level atomic rollback significantly reduces system downtime, ensuring high availability while preventing system crashes caused by firmware update failures. By restoring the file system and service state, seamless rollback of firmware updates is achieved, improving the flexibility and reliability of the update process.

[0115] In this embodiment, firmware rollback includes:

[0116] By comparing the current system state with historical records, the minimum differential file required for firmware rollback is generated, and firmware rollback is performed based on the minimum differential file.

[0117] Among these methods, the efficiency of rollback operations is optimized and recovery time is reduced by utilizing the minimum difference file.

[0118] In this embodiment, firmware rollback includes:

[0119] During the firmware rollback and data recovery process, based on the key status information in the rollback certificate, data blocks in the file system that have not yet been modified are restored first. If the file system cannot be fully restored, a rollback operation is triggered and an alarm message is sent.

[0120] Prioritize the recovery of unmodified data blocks in the file system to reduce recovery time and improve efficiency. Initiate an automatic system repair process when an alarm is sent.

[0121] In the aforementioned firmware secure hot update method, a differential patch file is generated by comparing the target firmware image with the current firmware image to verify the integrity and source of the patch. After verifying the trustworthiness of the patch behavior using a shadow execution environment, a rollback certificate is created and the firmware is updated. By verifying the trustworthiness and integrity of the patch file behavior in the shadow execution environment, the impact of erroneous or malicious patches on system stability and security is avoided. The rollback mechanism ensures that the system state can be quickly restored in the event of an anomaly, minimizing the risks during the update process and achieving seamless recovery without the need for a reboot.

[0122] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0123] In one embodiment, such as Figure 3 As shown, a firmware security hot update device 10 is provided, including: a differential patch generation module 1, a trust chain generation module 2, a shadow execution environment verification module 3, a firmware update module 4, and a rollback and recovery module 5.

[0124] The differential patch generation module 1 is used to compare the target firmware image with the currently running firmware image to obtain a differential patch file.

[0125] The trust chain generation module 2 is used to verify the integrity metric of the differential patch file and its source information, and to bind the integrity metric of the differential patch file and its source information together to form a trust chain extension record.

[0126] The shadow execution environment verification module 3 is used to load the differential patch file in the hardware-isolated shadow execution environment. It confirms whether the differential patch file is trustworthy by comparing whether the response output of the main runtime environment and the shadow execution environment to the same query business request is consistent.

[0127] Firmware update module 4 is used to respond to the trustworthiness of the differential patch file confirmation behavior, create a snapshot of the current file system, extract key status information and encapsulate it into rollback credentials, and apply the differential patch file to the current file system of the main runtime environment to complete the firmware update.

[0128] The rollback and recovery module 5 is used to roll back the file system and restore the critical state based on the rollback credentials when an abnormality is detected in the main runtime environment or when there is inconsistency with the trust chain extension record, thereby realizing the firmware rollback of the main runtime environment.

[0129] In this embodiment, comparing the target firmware image with the currently running firmware image to obtain the differential patch file includes:

[0130] The binary differential algorithm is used to compare the executable code segment, configuration data segment and file system layout of the target firmware image with the currently running firmware image block by block to identify the data areas that have changed in content or address.

[0131] Generate a differential description file containing the modified offset, original data length, and new data content based on the area data that has changed in content or address;

[0132] The differential description file is stored in a compressed encoding format to generate a differential patch file.

[0133] In this embodiment, verifying the integrity metric of the differential patch file and its source information, and jointly binding the integrity metric of the differential patch file and its source information to form a trust chain extension record includes:

[0134] The differential patch file is hashed to obtain an integrity metric, which is then written to the Platform Configuration Register (PCR register) in the Trusted Platform Module (TPM).

[0135] Extract the unique identifier of the signature subject from the digital signature of the differential patch file, and perform a hash operation on the unique identifier of the signature subject to obtain the hash digest value;

[0136] The extended trust chain record is determined based on the hash digest value and the current register value of the platform configuration register.

[0137] In this embodiment, determining the extended trust chain record based on the hash digest value and the current register value of the platform configuration register includes:

[0138] Get the current register value after the integrity metric value is written to the platform configuration register;

[0139] Obtain the hash digest value that uniquely identifies the signature subject;

[0140] The current register value is updated by performing a bitwise XOR operation between the hash digest value and the current value of the platform configuration register, which is used to establish a joint binding relationship between integrity and source information, forming an extended trust chain record.

[0141] In this embodiment, loading the differential patch file in a hardware-isolated shadow execution environment and confirming the trustworthiness of the differential patch file by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query service request includes:

[0142] A shadow execution space, isolated from the main runtime environment, is constructed to form a shadow execution environment. Service modules updated by differential patch files are deployed within the shadow execution space.

[0143] When the main runtime environment receives a query request, it copies the query request to the shadow execution environment and triggers the same processing flow.

[0144] The response codes, return data structures, and abnormal status flags output by the main runtime environment and the shadow execution environment are compared field by field. If the results of multiple consecutive comparisons are completely consistent and the shadow execution environment does not crash or time out, the behavior of the differential patch file is determined to be trustworthy.

[0145] In this embodiment, when comparing the response codes, return data structures, and exception status flags output by the main runtime environment and the shadow execution environment field by field, the expression used to determine the credibility of the differential patch file behavior is:

[0146] ;

[0147] In the formula, This represents the response output of the main runtime environment to the k-th query request. This represents the response output of the shadow execution environment to the k-th query request. This indicates whether an exception occurred during the execution of the k-th query request in the shadow execution environment; ∧ represents a logical AND operation. This condition is true if it is met for all query requests from k=1 to k=N. This indicates a comparison of whether the two responses on both sides of the equals sign are equal. This indicates a logical NOT operation, and Trusted (△F) indicates that the behavior of the differential patch file is trustworthy;

[0148] When N consecutive comparisons all meet the requirement of consistent response and no anomalies, the differential patch file is determined to have reliable behavior.

[0149] In this embodiment, before loading the differential patch file in the hardware-isolated shadow execution environment, the following steps are also included:

[0150] Collect the current system load and obtain a system updability score based on the load.

[0151] When the system updability score is greater than a preset threshold, a shadow execution space isolated from the main runtime environment is constructed to form a shadow execution environment.

[0152] In this embodiment, the current system load is collected, and the system updability score is obtained based on the operating load, including:

[0153] The system acquires in real time the number of pending requests in the current system's command queue, the scheduling cycle deviation rate of sensor sampling tasks, and the transmission frequency of data bus (D-Bus) messages per unit time to form load indicators.

[0154] The difference between each load index and the corresponding preset low load benchmark value is calculated, multiplied by the corresponding service criticality weight coefficient, and then summed. After linear normalization, it is mapped to the standard interval, and a comprehensive score representing whether the system is currently suitable for hot update is output as the system updateability score.

[0155] In this embodiment, the difference between each load index and its corresponding preset low load benchmark value is calculated, multiplied by the corresponding service criticality weight coefficient, and then summed. This summation is then mapped to a standard interval through linear normalization, outputting a comprehensive score characterizing whether the system is currently suitable for hot updates. This score serves as the system updateability score and includes:

[0156] Get the actual load value Li of the i-th service, and get the low load baseline value corresponding to the i-th service. Get the maximum load capacity of the i-th service. Obtain the weight coefficient wi of the i-th service in the system;

[0157] pass Calculate the normalized system updability score .

[0158] In this embodiment, creating a snapshot of the current file system, extracting key state information, encapsulating it into rollback credentials, and applying the differential patch file to the current file system of the main runtime environment to complete the firmware update includes:

[0159] The file system state is locked before firmware updates via copy-on-write mechanism;

[0160] Create a snapshot of the current root file system;

[0161] Extract the hash value of the current firmware executable file, the content summary of key configuration files in the system configuration directory, the sequence of instructions that have not yet been executed in the command queue, and the list of service object paths registered on the data bus to form key status information;

[0162] Encapsulate instantaneous snapshots and critical status information into rollback credentials and store them in a separate reserved area;

[0163] The updated content in the differential patch file is written to the current file system of the copy-on-write file system, triggering the relevant service process to reload the module that updates the differential patch file.

[0164] In this embodiment, when encapsulating the instantaneous snapshot and key state information into rollback credentials and storing them in a separate retention area, the method further includes:

[0165] The key status information in the rollback certificate is encrypted and stored using a public-key symmetric encryption algorithm, so that the key of the rollback certificate can be decrypted through a secure channel during the recovery process.

[0166] In this embodiment, in response to detecting an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the firmware rollback of the main runtime environment is achieved by rolling back the file system and restoring the critical state based on the rollback credentials, including:

[0167] If a service crash is detected after a firmware update, the value of the platform configuration register (PCR register) cannot be verified by remote proof, or a critical task response times out, the current file system will be stopped.

[0168] The file system is rolled back to the instantaneous snapshot version before the update, and the queue state and data bus service registration information are restored according to the contents recorded in the rollback certificate, so as to achieve millisecond-level atomic rollback of firmware without restarting.

[0169] In the aforementioned firmware security hot update device, a differential patch file is generated by comparing the target firmware image with the current firmware image to verify the integrity and source of the patch. After verifying the trustworthiness of the patch behavior using a shadow execution environment, a rollback certificate is created and the firmware is updated. By verifying the trustworthiness and integrity of the patch file behavior in the shadow execution environment, the impact of erroneous or malicious patches on system stability and security is avoided. The rollback mechanism ensures that the system state can be quickly restored in the event of an anomaly, minimizing the risks during the update process and achieving seamless recovery without the need for a reboot.

[0170] For a description of the features in the embodiment corresponding to the firmware secure hot update device, please refer to the relevant description of the embodiment corresponding to the firmware secure hot update method, which will not be repeated here.

[0171] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the firmware security hot update method embodiments described above.

[0172] In one embodiment, the electronic device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores firmware secure hot-update data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a firmware secure hot-update method.

[0173] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the firmware security hot update method embodiments described above when running:

[0174] The target firmware image is compared with the currently running firmware image to obtain the differential patch file;

[0175] The integrity metric of the differential patch file and its source information are verified, and the integrity metric of the differential patch file and its source information are jointly bound to form a trust chain extension record;

[0176] Load the differential patch file in the hardware-isolated shadow execution environment, and verify the reliability of the differential patch file by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request.

[0177] In response to the trustworthy behavior of the differential patch file, a snapshot of the current file system is created and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main runtime environment to complete the firmware update.

[0178] In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment's firmware is rolled back based on the rollback credentials, and the critical state is restored.

[0179] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0180] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the firmware secure hot update method embodiments described above:

[0181] The target firmware image is compared with the currently running firmware image to obtain the differential patch file;

[0182] The integrity metric of the differential patch file and its source information are verified, and the integrity metric of the differential patch file and its source information are jointly bound to form a trust chain extension record;

[0183] Load the differential patch file in the hardware-isolated shadow execution environment, and verify the reliability of the differential patch file by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request.

[0184] In response to the trustworthy behavior of the differential patch file, a snapshot of the current file system is created and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main runtime environment to complete the firmware update.

[0185] In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment's firmware is rolled back based on the rollback credentials, and the critical state is restored.

[0186] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the firmware secure hot update method embodiments described above:

[0187] The target firmware image is compared with the currently running firmware image to obtain the differential patch file;

[0188] The integrity metric of the differential patch file and its source information are verified, and the integrity metric of the differential patch file and its source information are jointly bound to form a trust chain extension record;

[0189] Load the differential patch file in the hardware-isolated shadow execution environment, and verify the reliability of the differential patch file by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request.

[0190] In response to the trustworthy behavior of the differential patch file, a snapshot of the current file system is created and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main runtime environment to complete the firmware update.

[0191] In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment's firmware is rolled back based on the rollback credentials, and the critical state is restored.

[0192] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0193] The firmware secure hot update method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for secure hot-updating firmware, characterized in that, include: The target firmware image is compared with the currently running firmware image to obtain the differential patch file; The integrity metric of the differential patch file and its source information are verified, and the integrity metric of the differential patch file and its source information are jointly bound to form a trust chain extended record; The differential patch file is loaded in a hardware-isolated shadow execution environment. The reliability of the differential patch file is confirmed by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query business request. In response to the confirmation that the differential patch file behavior is trustworthy, a snapshot of the current file system is created and key status information is extracted and encapsulated into rollback credentials. The differential patch file is then applied to the current file system of the main operating environment to complete the firmware update. In response to the detection of an abnormal operation of the main runtime environment or inconsistency with the trust chain extension record, the main runtime environment's firmware is rolled back based on the rollback credential and the critical state is restored.

2. The firmware secure hot update method according to claim 1, characterized in that, The step of comparing the target firmware image with the currently running firmware image to obtain the differential patch file includes: The binary differential algorithm is used to compare the executable code segment, configuration data segment and file system layout of the target firmware image with the currently running firmware image block by block to identify the data areas that have changed in content or address. Generate a differential description file containing the modified offset, original data length, and new data content based on the area data that has changed in content or address; The differential description file is stored in a compressed encoding format to generate a differential patch file.

3. The firmware secure hot update method according to claim 1, characterized in that, The step of verifying the integrity metric of the differential patch file and its source information, and jointly binding the integrity metric of the differential patch file and its source information to form a trust chain extension record includes: The differential patch file is hashed to obtain an integrity metric value, and the integrity metric value is written into the platform configuration register in the trusted platform module. Extract the unique identifier of the signature subject from the digital signature of the differential patch file, and perform a hash operation on the unique identifier of the signature subject to obtain a hash digest value; The extended trust chain record is determined based on the hash digest value and the current register value of the platform configuration register.

4. The firmware secure hot update method according to claim 3, characterized in that, The step of determining the extended trust chain record based on the hash digest value and the current register value of the platform configuration register includes: Obtain the current register value after the integrity metric value is written to the platform configuration register; Obtain the hash digest value of the unique identifier of the signature subject; The current register value is updated by performing a bitwise XOR operation between the hash digest value and the current value of the platform configuration register, thereby establishing a joint binding relationship between integrity and source information and forming an extended trust chain record.

5. The firmware secure hot update method according to claim 1, characterized in that, The step of loading the differential patch file in a hardware-isolated shadow execution environment and confirming the trustworthiness of the differential patch file by comparing the response outputs of the main runtime environment and the shadow execution environment to the same query service request includes: A shadow execution space isolated from the main runtime environment is constructed to form a shadow execution environment, and service modules updated by the differential patch file are deployed in the shadow execution space; When the main runtime environment receives a query service request, it copies the query service request to the shadow execution environment and triggers the same processing flow. The response codes, return data structures, and abnormal status flags output by the main runtime environment and the shadow execution environment are compared field by field. If the results of multiple consecutive comparisons are completely consistent and the shadow execution environment has not crashed or timed out, the behavior of the differential patch file is determined to be trustworthy.

6. The firmware secure hot update method according to claim 5, characterized in that, When comparing the response codes, return data structures, and exception status flags output by the main runtime environment and the shadow execution environment field by field, the expression used to determine the credibility of the differential patch file behavior is: ； In the formula, This represents the response output of the main runtime environment to the k-th query request. This represents the response output of the shadow execution environment to the k-th query request. This indicates whether an exception occurred during the execution of the k-th query request in the shadow execution environment; ∧ represents a logical AND operation. This condition is true if it is met for all query requests from k=1 to k=N. This indicates a comparison of whether the two responses on both sides of the equals sign are equal. This indicates a logical NOT operation, and Trusted (△F) indicates that the behavior of the differential patch file is trustworthy; When N consecutive comparisons all meet the requirement of consistent response and no anomalies, the differential patch file is determined to have reliable behavior.

7. The firmware secure hot update method according to claim 6, characterized in that, Before loading the differential patch file in a hardware-isolated shadow execution environment, the following is also included: Collect the current system load and obtain a system updability score based on the load. When the system updability score is greater than a preset threshold, a shadow execution space isolated from the main runtime environment is constructed to form a shadow execution environment.

8. The firmware secure hot update method according to claim 7, characterized in that, The process of collecting the current system's operating load and obtaining a system updability score based on the operating load includes: The system acquires in real time the number of pending requests in the current system's command queue, the scheduling cycle deviation rate of sensor sampling tasks, and the transmission frequency of data bus messages per unit time to form load indicators. The difference between the actual load value of each load indicator and the corresponding preset low load benchmark value is calculated, multiplied by the corresponding service criticality weight coefficient, and then summed. After linear normalization, it is mapped to the standard interval, and a comprehensive score representing whether the system is currently suitable for hot update is output as the system updateability score.

9. The firmware secure hot update method according to claim 8, characterized in that, The process of calculating the difference between the actual load value of each load indicator and the corresponding preset low load benchmark value, multiplying each difference by the corresponding service criticality weight coefficient, summing the results, and then mapping them to a standard interval through linear normalization, outputting a comprehensive score characterizing whether the system is currently suitable for hot updates as a system updateability score includes: Get the actual load value L of the i-th service. i Obtain the low load baseline value corresponding to the i-th service. Get the maximum load capacity of the i-th service. Obtain the weight coefficient w of the i-th service in the system. i ; pass Calculate the normalized system updability score.

10. The firmware secure hot update method according to claim 1, characterized in that, The step of creating a snapshot of the current file system, extracting key state information, encapsulating it into rollback credentials, and applying the differential patch file to the current file system of the main runtime environment to complete the firmware update includes: The file system state is locked before firmware updates via copy-on-write mechanism; Create a snapshot of the current root file system; Extract the hash value of the current firmware executable file, the content summary of key configuration files in the system configuration directory, the sequence of instructions that have not yet been executed in the command queue, and the list of service object paths registered on the data bus to form key status information; The instantaneous snapshot and the key status information are encapsulated into rollback credentials and stored in a separate retention area; The updated content in the differential patch file is written to the current file system of the copy-on-write file system, triggering the relevant service process to reload the module that updates the differential patch file.

11. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the firmware secure hot update method as described in any one of claims 1 to 10 when executing the computer program.

Images