A BIOS dual-mirror configuration encryption synchronization and trusted recovery method and device

Abstract

The application provides a BIOS dual-mirror configuration encryption synchronization and trusted recovery method and device, and belongs to the field of server firmware configuration management. The method comprises the following steps: in response to a change in a configuration item of a BIOS main mirror, a BMC acquires the changed configuration information, performs encryption processing on the configuration information, and constructs a structured backup package; the structured backup package is stored in a local non-volatile storage area of the BMC, and the backup package stored in the local non-volatile storage area is subjected to index management; in response to detecting that the BIOS switches from the BIOS main mirror to a BIOS backup mirror to start, the BMC reads the backup package from the local non-volatile storage area, and performs security verification on the backup package; after the security verification is passed, the BMC loads the configuration information in the backup package to the BIOS backup mirror. The method and device provided by the application can realize encryption synchronization and trusted recovery of BIOS dual-mirror configuration.

Description

Technical Field

[0001] This application relates to the field of server firmware configuration management technology, and in particular to a method and apparatus for BIOS dual-mirror configuration encryption synchronization and trusted recovery. Background Technology

[0002] To address the risk of single-point-of-failure firmware failures, modern servers commonly employ BIOS dual-mirror technology, storing the BIOS firmware in two physically isolated flash memory areas: one as the primary image and the other as a backup image. When the primary image fails to boot due to upgrade failure, physical damage, or malicious attack, the system hardware can automatically switch to the backup image to complete the boot process, achieving firmware-level redundancy and disaster recovery.

[0003] In a dual-BIOS architecture, besides the BIOS firmware code, the synchronization of BIOS configuration data also determines whether the server can operate normally after a switchover. BIOS configuration covers multiple categories, including processor parameters, memory configuration, platform power policies, I / O configuration, management configuration, and boot configuration. Modifications made by the user to these configuration items in the BIOS settings interface directly determine the server's operating parameters and performance policies. If the backup image lacks configuration data consistent with the primary image, even if the server can boot successfully, the use of factory default or outdated configurations will lead to the loss of business policies and deviations from expected operating parameters. Maintenance personnel must manually intervene and reconfigure, resulting in uncontrollable recovery windows and maintenance costs.

[0004] Currently, there are several studies in the industry on handling BIOS dual-mirror configuration synchronization. One BIOS firmware synchronization solution automatically synchronizes the firmware and configuration to the backup BIOS after the primary BIOS firmware is updated via the BMC. In the event of a boot failure on the primary storage medium, it switches over and applies the latest configuration. This solution focuses on synchronization triggered by firmware update events and lacks a mechanism to capture real-time modifications to configuration items by users during normal operation. Another BIOS configuration update hardening solution synchronizes configuration values ​​to the BMC during BIOS boot and restores them during version upgrades using the configuration values ​​stored in the BMC. This solution primarily addresses configuration retention during version upgrades, not the configuration recovery needs in dual-mirror failure switching scenarios. A configuration information management solution based on external storage saves configuration information logs to a file server. When the primary BMC fails, the backup BMC retrieves the latest configuration from the file server. This solution relies on external network storage and carries the risk of backup unavailability due to network link failures.

[0005] From a security perspective, the above solutions still have some shortcomings. Both the BIOS firmware synchronization and configuration update hardening solutions store configuration data in unencrypted form during the synchronization process. The file server solution also lacks encryption protection and integrity verification during transmission and storage, leaving configuration data vulnerable to leakage and tampering. Furthermore, backup configurations generally lack a unique binding mechanism to specific devices, allowing backup data to be copied to other devices and reused; the lack of timeliness control means that expired historical configurations may be mistakenly used for recovery operations. In summary, existing solutions have not yet formed a complete closed loop for BIOS configuration backup and recovery in terms of real-time performance, security, and reliability. Summary of the Invention

[0006] In view of this, this application provides a BIOS dual-mirror configuration encryption synchronization and trusted recovery method and apparatus to solve the problems in existing BIOS dual-mirror schemes, such as the loss of business policies due to outdated backup mirror configuration after fault switching, requiring manual reconfiguration, and the lack of security mechanisms such as encryption, device binding and timeliness control in backup configuration.

[0007] Specifically, this application is implemented through the following technical solution:

[0008] The first aspect of this application provides a method for encrypted synchronization and trusted recovery of BIOS dual-mirror configuration, the method comprising:

[0009] In response to a change in the configuration items of the BIOS master image, the BMC obtains the changed configuration information, encrypts the configuration information, and constructs a structured backup package by combining the device identification information and timeliness control information.

[0010] The BMC stores the structured backup package in its local non-volatile storage area and performs index management on the backup package stored in the local non-volatile storage area.

[0011] In response to detecting that the BIOS has switched from the BIOS primary image to the BIOS backup image for booting, the BMC reads the backup package from the local non-volatile storage area and performs a security verification on the backup package;

[0012] After the security verification is passed, the BMC loads the configuration information in the backup package into the BIOS backup image.

[0013] A second aspect of this application provides a BIOS dual-mirror configuration encryption synchronization and trusted recovery device, the device comprising a processing module, a management module, a verification module and a loading module;

[0014] The processing module is used to respond to changes in the configuration items of the BIOS master image. The BMC obtains the changed configuration information, encrypts the configuration information, and constructs a structured backup package by combining the device identification information and timeliness control information.

[0015] The management module is used to store the structured backup package in the local non-volatile storage area of ​​the BMC, and to perform index management on the backup package stored in the local non-volatile storage area.

[0016] The verification module is used to read the backup package from the local non-volatile storage area and perform security verification on the backup package in response to detecting that the BIOS has switched from the BIOS primary image to the BIOS backup image for booting.

[0017] The loading module is used so that, after the security verification is passed, the BMC loads the configuration information in the backup package into the BIOS backup image.

[0018] The BIOS dual-image configuration encryption synchronization and trusted recovery method and apparatus provided in this application realizes the automatic generation and management of BIOS images without the need for manual backup. When configuration changes occur, the BMC automatically captures and encrypts the structured backup package, and saves both firmware changes and configuration changes in a single backup. The backup package is stored in the local non-volatile storage area of ​​the BMC and indexed. When a primary image failure is detected and the system switches to the backup image, the backup package is automatically read, and after security verification, the configuration is loaded. Overall, the encrypted synchronization and trusted recovery of BIOS dual-image configuration is realized, upgrading the traditional BIOS dual-image solution from firmware-level redundancy to a fully closed-loop disaster recovery that synchronizes firmware and configuration. Specifically, in response to changes in the BIOS master image configuration, the BMC obtains and encrypts the changed configuration information, combines it with device identification information and timeliness control information to construct a structured backup package, and automatically completes the backup at the moment of configuration change without manual intervention. The backup package is stored in the BMC's local non-volatile storage area, so that the access to backup data does not depend on external networks or file servers, avoiding the risk of backup unavailability due to network failures. The stored backup packages are indexed to ensure that the latest valid version can be quickly located among multiple backup packages. In response to detecting that the BIOS has switched from the master image to the standby image for boot, the BMC reads the backup package from local storage and performs security verification. After the verification is successful, the configuration is loaded into the standby image, so that the recovery operation is automatically triggered by the hardware switch event, and the standby image configuration is restored to the state before the failure, without the need for maintenance personnel to manually reconfigure. Attached Figure Description

[0019] Figure 1A flowchart of an embodiment of the BIOS dual-image configuration encryption synchronization and trusted recovery method provided in this application;

[0020] Figure 2 This is a schematic diagram of the second embodiment of the BIOS dual-image configuration encryption synchronization and trusted recovery device provided in this application. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0022] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0023] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0024] Example 1

[0025] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0026] Figure 1 This is a flowchart of an embodiment of the BIOS dual-image configuration encryption synchronization and trusted recovery method provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0027] S101. In response to a change in the configuration items of the BIOS master image, the BMC obtains the changed configuration information, encrypts the configuration information, and constructs a structured backup package by combining the device identification information and timeliness control information.

[0028] It's important to note that the detection of changes to BIOS (Basic Input Output System) configuration items is not achieved by the BMC (Baseboard Management Controller) through its own polling. The BIOS is the primary entity directly handling user configuration operations. After a user modifies BIOS configuration items, the BIOS proactively sends a configuration change notification and the modified configuration information to the BMC via the Intelligent Platform Management Interface (IPMI) command. IPMI is a mature hardware management interface standard that defines the request / response message format between the BMC and system software. This embodiment utilizes IPMI commands to establish a communication channel for configuration changes between the BIOS and BMC. When the BMC receives the corresponding IPMI command, it detects the configuration change and then retrieves the modified configuration information from the BIOS. This proactive notification from the BIOS, rather than BMC polling, allows for timely response without consuming additional polling resources.

[0029] It's important to note that before performing the encryption and build operations for the backup package, the BMC first assesses its current processor utilization and memory usage. As the server's baseboard management controller, the BMC's primary responsibility is to monitor and manage server hardware. Encryption is a computationally intensive operation; if performed during periods of high BMC processor load, it may affect the BMC's polling of hardware sensor data and alarm responses. The BMC maintains an internal workload monitoring module that collects its own processor utilization and available memory capacity in real time. When the BMC receives a configuration change notification, the workload monitoring module reads the current processor utilization and available memory capacity: if the processor utilization is below a preset high-load threshold (e.g., 70%) and available memory is sufficient, the BMC immediately performs the encryption and build operations for the backup package; if the processor utilization is above the high-load threshold or available memory is insufficient, the BMC does not directly suspend the backup task. Instead, it first determines the difference in processor utilization and memory required to execute the backup task—the gap between currently available resources and the resources required for the backup task. Secondly, it identifies the importance level of the configuration items involved in this configuration change within the overall BIOS configuration. The BIOS Configuration Management (BMC) analyzes the changed configuration items. Based on the number of configuration items involved, the security sensitivity level of each item in the configuration item hierarchy table, and the magnitude of value changes for each item, it comprehensively assesses the importance level of this change within the overall BIOS configuration. When the importance level is higher than the preset importance threshold, it indicates that this change involves critical configuration items and the changes are significant, requiring priority to ensure the timely execution of backup tasks.

[0030] When the importance level is higher than the importance threshold, BMC iterates through all its currently executing and pending tasks, and filters out tasks with timeliness requirements lower than a preset timeliness threshold from the task queue as a candidate set of tasks that can be suspended. The task timeliness requirements include the latest completion time of the task and the maximum tolerable time for delayed execution. Tasks with timeliness requirements lower than the timeliness threshold are allowed to be delayed without affecting BMC's core monitoring and management responsibilities.

[0031] BMC predicts the processor utilization and memory resources that each task in the candidate suspendable task set can provide after release, and compares them with the difference. If the resources provided after releasing all tasks in the candidate suspendable task set are greater than or equal to the difference, BMC suspends only a portion of the candidate tasks, with the number of suspended tasks limited to the amount of resources released just enough to meet the difference, while the remaining candidate tasks continue to execute normally. If the resources provided after releasing all tasks in the candidate suspendable task set are still less than the difference, all tasks in the candidate suspendable task set are suspended, and the current backup task is also suspended and placed in a delayed backup queue. The backup tasks in the queue will be executed sequentially after the processor utilization drops below the normal threshold or memory is released.

[0032] Tasks in the delayed backup queue are sorted by reception time, and the BMC consumes tasks in the queue one by one during processor idle periods. When the number of tasks backlogged in the delayed backup queue exceeds the preset queue depth limit, the BMC merges the earliest received tasks in the queue into a single batch backup operation to reduce the total queue consumption time. This backup priority scheduling mechanism, based on the BMC's own workload awareness, ensures that the BMC's core monitoring and management responsibilities are not interfered with by backup encryption operations, maintaining the responsiveness of the BMC's external management services while ensuring backup reliability.

[0033] It's important to note that upon receiving a configuration change notification, the BMC does not immediately trigger the generation of a backup package for every change. Internally, the BMC maintains a cumulative change window and a corresponding configuration change array. This array stores all configuration change items received within the current cumulative time window. When the BMC receives a new configuration change notification within a preset cumulative time window, it generates a timestamp for this change, recording the time of receipt. The BMC stores the timestamp and change item information together in the configuration change array. If a configuration item in the change item information is identical to an existing change item in the configuration change array, the BMC determines that the change has been duplicated. In this case, the BMC replaces the existing corresponding change item in the array with the current change item and updates the timestamp to the current receipt time, rather than adding a new record to the array. This replacement mechanism ensures that multiple modifications to the same configuration item within the cumulative window only retain the latest version, avoiding redundant backups due to repeated modifications to the same configuration item.

[0034] After the cumulative window expires, the BMC does not immediately merge and back up all changes in the configuration change array. Instead, it first performs a primary-secondary analysis on each configuration item in the array. This analysis involves the BMC querying a configuration item hierarchy table to categorize items into primary and secondary categories. Primary items include critical configurations affecting system startup capabilities, hardware security boundaries, and the start / stop of virtualization functions; secondary items include non-critical configurations such as boot order and startup timeout. If a primary configuration item exists in the configuration change array, the BMC immediately triggers the generation of a backup package, without waiting for the cumulative window to expire, and directly merges all currently accumulated changes in the array into a single batch to generate a structured backup package. If the configuration change array contains only secondary configuration items, the BMC waits for the originally scheduled cumulative window to expire before merging all changes in the array to generate a backup package. This dynamic triggering mechanism based on primary-secondary configuration item analysis ensures that changes to critical configurations are captured and backed up instantly, avoiding delays in backup due to waiting for the cumulative window.

[0035] If there is only one configuration change within the cumulative time window, the BMC will directly generate a backup package for that change. The length of the cumulative time window is adaptively adjusted by the BMC based on the historical frequency of configuration changes. When the BMC detects that the frequency of configuration changes exceeds a preset frequency threshold, it automatically extends the cumulative window to merge more changes, reducing the number of backup packages generated and the number of eMMC writes; when the change frequency is low, the cumulative window is shortened to reduce the latency of a single backup. This adaptive batch processing mechanism allows the backup triggering strategy to be dynamically adjusted according to the user's operating habits and the intensity of configuration changes, achieving a balance between backup real-time performance and storage efficiency.

[0036] After obtaining the modified configuration information, the BMC does not directly store the original configuration data. Instead, it encrypts the configuration information and combines it with device identification information and timeliness control information to construct a structured backup package. Encryption is used because BIOS configuration information is a core operating parameter of the server. If stored in plaintext, an attacker could directly obtain the server's complete configuration policy if the backup package is illegally read, posing a security risk. Encryption ensures that even if the backup package is illegally obtained, an attacker cannot recover the original configuration information from it.

[0037] The specific steps for encryption and backup package construction are explained below.

[0038] First, the encryption process for the configuration information includes:

[0039] It should be noted that this embodiment uses a symmetric encryption algorithm to encrypt the configuration information. Symmetric encryption uses the same key for both encryption and decryption, offering advantages such as fast encryption / decryption speed and suitability for large-scale data processing. The encryption key is dynamically generated by the BMC's built-in security engine. The security engine is a hardware module within the BMC chip responsible for key generation and cryptographic operations. The key generation is completed internally within the hardware, without going through an external bus, thus reducing the risk of key leakage at the source.

[0040] (1) The security engine of the BMC generates an encryption key based on the configuration information, the device identification information and the backup package generation timestamp.

[0041] Each time a backup package is generated, the BMC security engine regenerates a new encryption key, instead of using a fixed key. Key generation is based on the changed configuration information, device identification information, and the backup package's generation timestamp. This combination of information ensures uniqueness, guaranteeing that each generated encryption key is different, and that there is a one-to-one correspondence between each backup package and its encryption key. This one-time pad key mechanism prevents attackers from using the same key to decrypt other backup packages even if the key for one backup package is cracked, limiting the impact of key leakage to a single session.

[0042] It should be noted that when the security engine generates encryption keys, the randomness originates from the BMC's internal hardware random number generator. This generator utilizes physical phenomena such as internal thermal noise or oscillator jitter to produce a true random number seed. This seed is then expanded into the required key material using a deterministic random bit generator conforming to the NIST SP 800-90A standard. After key generation, the security engine writes the key directly to the SPI ROM controller via a dedicated register within the BMC, bypassing the system bus and not residing in the BMC's volatile memory. After the backup package construction process is complete, the BMC immediately erases the plaintext key from the security engine's internal registers, ensuring that the key's lifespan in memory is limited to a single backup package construction process. When a backup package is deleted due to cyclic overwriting or expiration cleanup, the BMC simultaneously deletes the corresponding encryption key from the SPI ROM and overwrites the key storage location with all zeros, ensuring that the key corresponding to the deleted backup package cannot be recovered.

[0043] (2) The configuration information is encrypted using the encryption key by employing a symmetric encryption algorithm.

[0044] BMC uses the generated encryption key and a symmetric encryption algorithm to encrypt the changed configuration information. The encryption process is completed within BMC's security engine. The encrypted configuration information exists in ciphertext form and cannot be read or parsed without decryption.

[0045] It should be noted that before encrypting the configuration information, the BMC first classifies the security sensitivity of the changed configuration items. The BMC maintains an internal configuration item classification table, dividing BIOS configuration items into high-sensitivity and ordinary configuration items according to their security impact. High-sensitivity configuration items include those related to system security policies, user authentication credentials, and encrypted certificate storage, while ordinary configuration items include non-security configurations such as boot order and boot timeout. When the changed configuration items include high-sensitivity items, the BMC uses the AES-256 encryption algorithm to encrypt all changed configuration information and additionally calculates an HMAC-SHA256 authentication code separately for the high-sensitivity configuration items, appending it to the extended field of the backup package. AES-256 is a widely validated symmetric encryption algorithm; its 256-bit key length is considered computationally secure enough to resist currently known brute-force attacks. When the changed configuration items only contain ordinary configuration items, the BMC uses the AES-128 encryption algorithm to reduce the computational overhead on BMC processing resources. It should be noted that, in addition to the encryption algorithms mentioned above, other symmetric encryption algorithms may also be selected based on actual security requirements and hardware encryption capabilities; this embodiment does not impose any restrictions on this. When parsing BIOS configuration item names, the BMC performs prefix matching between the configuration item name and pre-stored keywords in the hierarchy table to automatically determine the security sensitivity level of each configuration item. This adaptive encryption strategy based on the risk level of configuration items allows the BMC to concentrate its limited cryptographic resources on the protection of highly sensitive configuration items, achieving differentiated configuration between security and processing efficiency.

[0046] (3) Store the encryption key in the non-volatile storage partition of the BMC and record the correspondence between the encryption key and the backup package in the index table of the backup package.

[0047] The non-volatile storage partition is independent of the local non-volatile storage area where the backup package is located.

[0048] It should be noted that, to avoid the risk of obtaining the decryption key simply by acquiring the backup package, this embodiment employs a separate storage mechanism for the key and the backup package. The BMC does not directly package the encryption key into the backup package; instead, it stores it in a separate, non-volatile memory physically isolated from the backup package's storage area. Furthermore, to ensure accurate identification of the unique key paired with a specific backup package during subsequent recovery, the BMC establishes and records the binding relationship between the two in the backup package's index table.

[0049] Specifically, storing the encryption key in the non-volatile storage partition of the BMC includes:

[0050] (i) During the generation of the backup package, the encryption key is written into a pre-divided independent partition in the serial peripheral interface flash memory (SPI ROM) of the BMC.

[0051] During the backup package generation phase, the BMC's security engine dynamically generates a unique encryption key and encrypts the configuration information. The BMC then immediately stores the newly generated encryption key in a dedicated, pre-planned secure storage space. Specifically, this storage space is an independent partition within the BMC's built-in serial peripheral interface flash memory, specifically the SPI ROM. The SPI ROM is a dedicated non-volatile memory chip on the BMC, connected to the BMC main control chip via the serial peripheral interface bus. It stores the BMC's firmware and critical configurations. Allocating a separate partition within this SPI ROM to store the encryption key isolates it from other BMC data.

[0052] It should be noted that this write operation occurs during the generation of the backup package, ensuring that the key and the backup package are physically isolated at the time of creation. The key is generated and stored on a secure path within the BMC, without passing through an external bus, effectively reducing the risk of the key being intercepted during transmission.

[0053] (ii) When restoring the backup package, the encryption key corresponding to the backup package is read from the independent partition of the SPI ROM according to the correspondence recorded in the index table of the backup package.

[0054] The SPI ROM is connected to the BMC via an independent bus, and is physically located on a different hardware circuit than the embedded multimedia storage card (eMMC) where the backup package is located.

[0055] When a backup package needs to be restored in the future, the BMC will not blindly search the SPI ROM, but will rely on an indexing mechanism. First, the BMC will look up the record corresponding to the backup package in the index table located in the eMMC backup package partition based on the identification information of the backup package to be restored, and extract the pre-stored encryption key identifier from the record. Then, the BMC will use this unique encryption key identifier as a basis to perform a precise match search in the independent partition of the SPI ROM. Once a match is successful, the BMC will read the unique key required to decrypt the backup package from the SPI ROM and send it to the security engine for subsequent configuration data decryption.

[0056] This design completely separates the backup package content (in the eMMC) from the credentials required to decrypt it (in the SPI ROM). The embedded multimedia storage card (eMMC) containing the backup package and the SPI ROM containing the key are connected to the BMC via independent hardware buses, physically located on different hardware circuits. Thus, even if an attacker obtains the complete backup package data stored on the eMMC, they will be unable to decrypt and recover any valid BIOS configuration information due to the lack of the corresponding decryption key physically residing in the separate SPI ROM chip, fundamentally ensuring the security of the backup data.

[0057] Secondly, after the configuration information is encrypted, BMC continues to build a structured backup package. The backup package is a structured data unit containing multiple fields, which are arranged in a preset order. BMC fills the encrypted configuration information, device identification information, timeliness control information, and integrity verification information into the corresponding fields.

[0058] Specifically, the construction of the structured backup package by combining device identification information and timeliness control information includes:

[0059] (1) Obtain the changed configuration information and encrypt the configuration information.

[0060] The first step in building the backup package is to prepare the encrypted configuration information. The BMC reads the changed configuration items from the BIOS master image, encrypts them according to the encryption process described above, and uses the encrypted ciphertext as the core payload of the backup package. The configuration information covers multiple categories, including processor configurations, memory configurations, platform power configurations, input / output configurations, management configurations, and boot configurations. Specifically, it includes various user-configurable parameters in the BIOS settings interface and their current values.

[0061] It's important to note that user modifications in the BIOS setup interface may only involve a small number of configuration items. When obtaining the changed configuration information, the BMC does not read all BIOS configuration items every time. Instead, based on the change item identifier carried in the IPMI command, it only retrieves the configuration item information that has actually changed, encrypts and packages it. For configuration items that have not changed, the BMC does not repackage them to reduce the size of the backup package and the computational overhead of encryption. When restoring the configuration, the BMC only writes the changed items carried in the backup package to the BIOS backup image. Configuration items that do not appear in the backup package retain their original values ​​in the BIOS backup image. This incremental backup and incremental restore design ensures that even if the granularity of the configuration change is very small, the backup package remains compact, and the restore operation will not interfere with other unchanged configuration items.

[0062] (2) Identify the device's model identification code, firmware version number and device serial number as the device identification information.

[0063] Device identification information is used to bind the backup package to the device that generated it, preventing the backup package from being misused after being illegally copied to other devices. The BMC reads the model identification code, firmware version number, and device serial number from the device's internal memory. The model identification code identifies the server's hardware model and platform type, the firmware version number records the current BIOS firmware version information, and the device serial number is a unique identifier assigned to the device at the factory. These three pieces of information together constitute a unique identifier for a specific device under a specific firmware version.

[0064] (3) Generate a backup package with a timestamp and a backup validity period as the timeliness control information.

[0065] Timeliness control information is used to limit the usage period of backup packages, preventing expired backup packages from being used for recovery operations. The Backup Management Console (BMC) obtains the current system time as the backup package generation timestamp, identifying the specific moment the backup package was created. Simultaneously, the BMC calculates the backup validity period based on the administrator's preset backup validity period and the generation timestamp. The backup validity period is the final deadline before the backup package is allowed to be used for recovery; backup packages exceeding this time will be marked as expired. The backup validity period is configured by the administrator according to security policies, such as 7 days, 30 days, or longer periods.

[0066] (4) Calculate the hash message authentication code of the configuration information and the device identification information.

[0067] To prevent backup packages from being tampered with during storage or transmission, BMC calculates a hash message authentication code for critical content within the backup package. BMC uses encrypted configuration information and device identification information as input and calculates the hash message authentication code using the HMAC-SHA256 algorithm. The hash message authentication code is a message integrity verification code based on a hash function; it relies on both input data and a key, and can simultaneously verify the integrity of the data and the authenticity of its source. During subsequent recovery, BMC recalculates the hash message authentication code and compares it with the value stored in the backup package. If the two do not match, it indicates that the backup package has been tampered with.

[0068] (5) The encrypted configuration information, the model identification code, the firmware version number, the device serial number, the generation timestamp, the backup validity period and the hash message authentication code are combined into the structured backup package according to the preset field order.

[0069] BMC combines the information generated in the above steps in a predefined field order to form a complete structured backup package. The predefined field order is the data format specification for the backup package, and BMC follows this specification when generating and parsing the backup package to ensure structural consistency.

[0070] Through the preceding content, this step completes the entire process from detecting configuration changes and encrypting configuration information to building a structured backup package. The backup package design considers three aspects of security: First, a one-time pad encryption mechanism ensures the confidentiality of configuration information; second, the security of the key is ensured by separating the key from the backup package and physically isolating the SPI ROM from the eMMC; finally, the device uniqueness and integrity of the backup package are ensured by binding device identification information and using hash message authentication codes.

[0071] S102, The BMC stores the structured backup package in the local non-volatile storage area of ​​the BMC, and performs index management on the backup package stored in the local non-volatile storage area.

[0072] It should be noted that the local non-volatile storage area for the backup package uses the eMMC (embedded multimedia memory card) integrated on the BMC. eMMC is a storage device that integrates flash memory chips and a controller onto a single chip. It features large capacity, fast read / write speeds, and moderate cost, and is widely used in embedded systems as a data storage medium. The BMC configures the eMMC as a file system, allocating a separate partition within the eMMC's total storage space specifically for storing the BIOS configuration backup package. This separate partition is isolated from the BMC's log storage area. The log storage area records the BMC's own system event logs and audit logs, while the backup package partition is only used to store the configuration backup package and index table files; neither consumes the other's storage space. This independent partitioning design, rather than hybrid storage, avoids frequent writes to the BMC logs that could crowd out the backup package storage, ensuring the stability and predictability of the backup package storage.

[0073] It's important to note that before writing the structured backup package to the eMMC, BMC dynamically determines whether to compress the backup package based on the current space occupancy of the backup package partition. BMC monitors the space occupancy of the backup package partition in real time. When the space occupancy is below a preset first threshold (e.g., 60%), the backup package is written directly in its uncompressed original format to ensure fast read speeds during recovery. When the space occupancy exceeds the first threshold but is below a preset second threshold (e.g., 85%), BMC compresses the backup package using the LZ4 compression algorithm before writing. The LZ4 algorithm features fast compression speed and low decompression latency, saving storage space without excessively increasing recovery latency. When the space occupancy exceeds the second threshold, BMC actively increases the cleanup effort of circular overwrite while compressing and writing, increasing the number of deletions per batch when deleting earlier backup packages to quickly free up more storage space. The compressed backup package is marked with a compression flag in the index table. During recovery, BMC automatically selects the corresponding decompression algorithm based on the compression flag. This adaptive compression and cleanup strategy based on storage space pressure enables BMC to maintain optimal recovery performance when eMMC storage space is plentiful, and automatically sacrifice a small amount of recovery latency in exchange for higher space utilization when storage space is tight.

[0074] After backup packages are stored in the eMMC, the BMC performs index management. The purpose of index management is to maintain an index table, which exists as a separate file in the eMMC's backup package partition. This index table records key metadata for each valid backup package in the current partition. Each time a new backup package is added, the BMC appends a new record to the index table and updates the index table file. Through the index table, the BMC can quickly locate the latest valid backup package without traversing the entire partition, improving recovery response speed. However, since the storage capacity of the eMMC is limited (e.g., a 128MB partition for backup packages, and a maximum size of 1MB for a single BIOS-configured backup package), storing multiple versions of backup packages within this limited space requires a well-designed space reclamation strategy to prevent partition space exhaustion and the inability to store new backup packages.

[0075] Specifically, the indexing and management of backup packages stored in the local non-volatile storage area includes:

[0076] (1) Create an index table to record the image identifier, package version and validity status fields of each backup package.

[0077] When BMC first stores backup packages in the eMMC backup package partition, it creates an index table file within that partition. The index table records metadata information for each valid backup package in the current partition. Each record contains at least the following three fields: Image ID, used to distinguish whether the backup package comes from the primary or standby image, facilitating identification of the backup package's origin during recovery; Package Version, which is the incrementing package version number assigned to the backup package in S101. A larger version number indicates a newer backup package, allowing for quick location of the latest backup package during recovery; and Validity Status, used to indicate whether the backup package is still within its validity period. If it has expired, no further verification is required.

[0078] Each time a new backup package is generated and stored in the eMMC, the BMC appends a new record to the index table, filling in the corresponding image identifier, package version, and validity status. The index table file is dynamically updated as backup packages are added and deleted, always reflecting the latest status of valid backup packages in the current partition.

[0079] It should be noted that the eMMC backup package partition is formatted as an EXT4 file system during the BMC's initial power-on initialization. The partition stores two types of files: backup package data files and index table files. Each backup package corresponds to an independent data file, named using the rule "bak_" followed by the package version number, such as bak_001 and bak_002. The file content is the complete structured backup package binary data generated by S101. The index table file, with the independent filename index.db, is stored in the partition's root directory. It uses a lightweight database format (such as SQLite's single-file storage format) to record the metadata of each backup package. The BMC performs CRUD operations on the index table through a standard database query interface. Both the backup package data files and the index table files are configured to be readable and writable only by the BMC management process through the file system's permission control mechanism; the operating system and other processes have no access permissions. When BMC detects an anomaly in the file system of the eMMC backup package partition, such as superblock corruption or inode inconsistency, BMC automatically performs file system repair operations. After the repair is completed, it performs CRC32 verification on all backup package data files and index table files in the partition. Backup packages that fail the verification are marked as invalid and removed from the index table.

[0080] (2) When the available space in the local non-volatile storage area is insufficient to store the new backup package, the earlier backup packages are deleted in chronological order.

[0081] Once the backup partition is planned, its available space is fixed. As users continuously modify the BIOS configuration, the system generates new backup packages and stores them in the partition with each configuration change, gradually reducing the remaining space. When the remaining available space in the partition is insufficient to accommodate newly generated backup packages, the BMC deletes earlier backup packages one by one, starting from the earliest generated backup package, according to chronological order (the order in which they were generated), until enough space is freed up for the new backup package to be written. The number of backup packages deleted depends on the size of the space to be freed up. For example, when a single backup package is about 1MB in size and the remaining space in the partition is less than 1MB, it may only be necessary to delete the earliest backup package; when the remaining space gap is large, it may be necessary to delete multiple earlier backup packages consecutively.

[0082] Early backup packages are deleted in chronological order rather than by other sorting methods because the configuration version corresponding to the earliest generated backup package is furthest from the current configuration state. Therefore, its actual value and probability of being used for recovery are the lowest, and prioritizing its deletion has the least impact on system recoverability. The index table records corresponding to the deleted backup packages are also removed synchronously to maintain consistency between the index table and the actual storage state.

[0083] (3) When the backup package exceeds the backup validity period, the expired backup package shall be deleted during the next configuration change.

[0084] In S101, a backup validity period is set for each backup package. Backup packages that have exceeded their validity period may have configuration data that no longer matches the current device's operating environment. Continuing to retain them not only occupies storage space but also poses a risk of misusing expired configurations during recovery. Each time a configuration change occurs or a new backup package is about to be generated, the BMC performs a validity period check on all backup packages in the index table, deleting expired backup packages from the eMMC and removing the corresponding records from the index table.

[0085] The timing for deleting expired backup packages is set to occur upon the next configuration change rather than immediately upon expiration. This is because the primary responsibility of the BMC in daily operation is server monitoring and management. Under normal circumstances without configuration changes, actively scanning and deleting expired backup packages would generate unnecessary computational and storage access overhead. However, when a configuration change occurs, the system is already in a state of reading and writing operations on the backup package partition. At this time, cleaning up expired backup packages at the same time can merge the two storage operations into one, reduce the number of writes to the eMMC, and improve overall efficiency.

[0086] It's important to note that when managing the index of backup packages, BMC also maintains a semantic tag field for each backup package in the index table. The semantic tag is generated by BMC extracting the names of the changed configuration items and their categories from the backup package. Following a preset category coding rule, the category codes for each change are concatenated into a string. This string is then hashed to generate a fixed-length semantic tag value, which is stored in the semantic tag field corresponding to that backup package in the index table. The semantic tag reflects the semantic characteristics of the configuration item categories and scope involved in the backup package, allowing for comparison between different backup packages based on the similarity of their semantic tags.

[0087] Before BMC performs expired backup package cleanup or cyclic overwrite deletion, it first compares the semantic tags of each backup package in the index table for similarity. BMC calculates the similarity between the semantic tags of the backup package to be deleted and the semantic tags of the remaining valid backup packages. Similarity can be measured using Hamming distance or cosine similarity, etc. When the semantic tag similarity of two backup packages exceeds a preset similarity threshold, it indicates that the configuration item categories and ranges involved in the two backup packages highly overlap, and BMC merges and stores the two backup packages. The specific method of merging and storing is as follows: BMC compares the values ​​of each configuration item in the two backup packages. For configuration items with exactly the same value, only one copy is retained in the merged backup package, and the newer timestamp is used to overwrite the older timestamp. For configuration items with different values, it indicates that different configuration changes have occurred at different points in time, and BMC retains both configurations in the merged backup package to cover a more complete configuration change history. After merging, BMC generates a new backup package data file, recalculates the semantic tags and updates the semantic tag fields of the corresponding records in the index table, and deletes the two original backup packages that were merged and their index table records. By comparing semantic tag similarity and merging storage, configuration change information that is still valuable in the backup package that was originally to be deleted is integrated and retained in the merged backup package, reducing the amount of configuration history information that is directly deleted due to storage space limitations and extending the traceability time of configuration change history as much as possible.

[0088] Through the aforementioned index management and space reclamation strategies, this step achieves orderly management of multiple version backup packages within the limited eMMC storage space. The index table provides fast retrieval capabilities, the cyclic overwrite strategy ensures that new backup packages are always stored, and the expiration cleanup strategy prevents invalid data from consuming storage resources. Storing backup packages on the BMC's local eMMC, rather than on external network storage devices, ensures that backup package access is independent of network link status. Even if the server network is interrupted, backup package storage and recovery can still be completed locally on the BMC, guaranteeing the reliability of the configuration recovery process.

[0089] Optionally, in a multi-node server cluster environment, the BMC can also store redundant copies of the backup package in the eMMC of other BMC nodes in the cluster. After each new backup package is generated and stored in its local eMMC, the BMC synchronously sends the backup package and its corresponding encryption key identifier to a pre-defined peer node BMC via the management network. Upon receiving the backup package, the peer node BMC stores it in a remote backup partition within its own eMMC, which is isolated from its own local backup package partition. If an unrecoverable hardware failure occurs in the local BMC's eMMC, resulting in the complete loss of local backup packages, the BMC, upon detecting that its local backup package partition is inaccessible, automatically initiates a remote backup package retrieval request to the peer node BMC. It then retrieves the latest valid backup package and its corresponding encryption key identifier from the peer node's remote backup partition for configuration recovery. The remote backup package is protected during transmission via a TLS encrypted channel between BMCs, ensuring secure transmission over the management network. This off-site redundancy design based on BMC collaboration provides disaster recovery protection at the level of single-node BMC hardware failure for backup packages, further improving the reliability of configuration recovery.

[0090] S103. In response to detecting that the BIOS has switched from the BIOS primary image to the BIOS backup image for booting, the BMC reads the backup package from the local non-volatile storage area and performs a security verification on the backup package.

[0091] It should be noted that when the primary BIOS image fails to boot due to upgrade failure, physical damage, or malicious attack, the server hardware will automatically switch the boot source to the backup BIOS image. While the backup image contains bootable BIOS firmware, its configuration data may remain at factory defaults or from an earlier configuration snapshot, differing from the latest configuration before the primary image failure. Therefore, upon detecting this switchover event, the latest valid backup package needs to be read from the BMC's local storage. Before loading its configuration into the backup image, a series of security checks are performed to ensure that the backup package to be restored is trustworthy, tamper-proof, and matches the current device and time.

[0092] In server motherboard design, the Complex Programmable Logic Device (CPLD) is responsible for managing low-level hardware control functions such as power-on timing, reset logic, and boot source selection. The CPLD has dedicated registers to record whether the current boot is from the primary or backup image. The BMC connects to the CPLD on the motherboard via the I2C interface, a widely used serial communication bus that supports data exchange between multiple devices using two signal lines. The BMC can actively read the register information within the CPLD using this interface.

[0093] Specifically, detecting that the BIOS has switched from the primary BIOS image to the backup BIOS image for booting includes:

[0094] (1) The BMC reads the register information of the CPLD through the I2C interface.

[0095] After system startup, the BMC periodically or during specific startup phases sends read requests to the CPLD via the I2C interface to obtain the contents of the status registers related to BIOS startup in the CPLD. This read process is initiated by the BMC and does not depend on the running status of the BIOS or operating system.

[0096] (2) Based on the BIOS image boot source recorded in the register information of the CPLD, determine whether to switch from the BIOS primary image to the BIOS backup image.

[0097] After obtaining the CPLD register information, the BMC parses the field recording the BIOS boot source, which identifies whether the BIOS firmware was loaded from the primary image or the backup image during this boot. The BMC compares the current boot source with the previously recorded boot source. When it detects that the boot source has changed from the primary image to the backup image, the BMC determines that a primary image to backup image switch event has occurred, and then triggers the backup configuration recovery process.

[0098] Among them, the method of using BMC to read CPLD registers through I2C to detect image switching allows the switching detection to be independent of the normal operation of BIOS or operating system. When the primary image fails, the BIOS itself cannot start normally, and it is not feasible to rely on the BIOS to actively report the switching event. However, BMC is a management controller independent of the main processor. Even if the main processor is in an abnormal state, BMC can still work normally through out-of-band channels to ensure that the switching event is reliably captured.

[0099] After detecting a mirror switch event, the BMC needs to read the latest valid backup package from the eMMC backup package partition of S102. However, since the configuration information in the backup package is encrypted in S101 and the encryption key is stored separately from the backup package, the BMC first needs to find the matching encryption key after reading the backup package to decrypt the encrypted configuration information in order to restore the original configuration data.

[0100] Specifically, reading the backup package from the local non-volatile storage area includes:

[0101] (1) Determine the encryption key identifier corresponding to the backup package based on the information recorded in the index table of the backup package.

[0102] The BMC first accesses the index table in the eMMC backup package partition. This index table records the image identifier, package version, and validity status of each backup package. The BMC locates the backup package with the highest version number (i.e., the most recently generated) and a valid validity status based on the package version number, and then extracts the corresponding encryption key identifier from the index table. The encryption key identifier is a unique identifier synchronously recorded in the index table during the S101 encryption process, when the BMC stores the encryption key in the SPI ROM. It is used to establish the pairing relationship between the backup package and the encryption key.

[0103] (2) Based on the encryption key identifier, search for an encryption key that matches the encryption key identifier in the non-volatile storage partition of the BMC.

[0104] After retrieving the encryption key identifier from the index table, the BMC uses this identifier as the basis for a search in the independent partition of the SPI ROM. The SPI ROM stores all the generated encryption keys, each associated with a unique encryption key identifier. The BMC traverses the key records stored in the independent partition of the SPI ROM, using the encryption key identifier as the matching key to find the encryption key that matches that identifier.

[0105] (3) Read the matched encryption key from the non-volatile storage partition and decrypt the encryption configuration information in the backup package.

[0106] The BMC reads the matched encryption key from the SPI ROM and sends it to its security engine. The security engine uses this key and the same AES-256 symmetric decryption algorithm as during encryption to decrypt the encrypted configuration information in the backup package, restoring the original BIOS configuration information. The decrypted configuration information is temporarily stored in the BMC's memory, awaiting subsequent security verification before being loaded into the BIOS backup image.

[0107] It should be noted that the entire key lookup and retrieval process is completed within the secure path of the BMC; the key is not transmitted via an external bus. The backup packet data stored in the eMMC and the encryption key stored in the SPI ROM are physically located on different hardware circuits and connected to the BMC via independent buses. Even if an attacker obtains all the backup packet files in the eMMC, they cannot obtain the corresponding decryption key from the SPI ROM, and therefore cannot recover the plaintext content of the configuration information.

[0108] After decrypting and restoring the original configuration information, the BMC does not immediately load it into the BIOS backup image. Instead, it first performs a series of security checks. The purpose of these security checks is to ensure that the backup package to be restored is trustworthy in multiple dimensions: the package itself is not expired, it is compatible with the current device and firmware version, and it truly belongs to the current device. The security check process includes the following four checks, which are executed sequentially according to a preset order.

[0109] Specifically, the security verification of the backup package includes:

[0110] (1) Verify the backup validity period of the backup package and determine whether the backup package is within the validity period.

[0111] The Backup Management Console (BMC) first checks the backup package's validity period. The validity period is the expiration date calculated during backup package creation in step S101 based on the administrator-set expiration date and generation timestamp. The BMC reads the backup validity period field from the backup package and compares the current system time with this validity period. If the current time has exceeded the backup validity period, the backup package is determined to be expired, subsequent verification processes are terminated, and an alarm message is output.

[0112] The reason for making validity period verification the first security check is that if the backup package has expired, it means that the configuration data may no longer be suitable for the current operating environment. Subsequent model compatibility and device binding verifications are meaningless. Terminating the verification in the first step can avoid unnecessary computational overhead and invalid verification operations.

[0113] (2) Verify whether the model identification code and firmware version number in the backup package are compatible with the model identification code and firmware version number of the current device.

[0114] After the validity period verification passes, BMC extracts the model identification code and firmware version number from the backup package. These two fields are written when the backup package is built to identify the hardware model and firmware version of the device that generated the backup package. BMC reads the corresponding model identification code and firmware version number from the current device and compares them separately. If the model identification code is inconsistent, it means that the backup package comes from a different model of server and is not suitable for the current device; if the firmware version number is incompatible, it means that the configuration parameters in the backup package may differ from the parameters supported by the current firmware version, and forced restoration may cause configuration abnormalities. If either comparison fails, the subsequent verification process is terminated and an alarm message is output.

[0115] (3) Verify whether the device serial number in the backup package is consistent with the serial number of the current device.

[0116] After the model and version verification passes, the BMC further extracts the device serial number from the backup package. The device serial number is a unique identifier assigned to the device at the factory and is written during the backup package construction in step S101, used to bind the backup package to the specific device that generated it. The BMC reads the serial number of the current device and compares it with the device serial number in the backup package. If they do not match, it indicates that the backup package originated from another device, for example, it may be a backup package migrated to the current device through illegal copying. The BMC determines that the backup package does not belong to the current device, terminates the verification process, and outputs an alarm message.

[0117] By binding the device serial number, even if an attacker copies a legitimate backup package to another server of the same model and attempts to trigger the recovery process by switching the backup image, the verification will fail because the device serial number recorded in the backup package is inconsistent with the current device, and the recovery process will be rejected.

[0118] (4) If any verification item fails, terminate the recovery process and output an alarm message.

[0119] The three checks described above are performed sequentially according to a preset order. If any check fails, the BMC immediately terminates the recovery process, stops executing subsequent checks, and records the failure event in the BMC's system event log. The alarm information includes the specific reason for the failure, the time of failure, the involved check items, and backup package information. Maintenance personnel can view the alarm log through the BMC management interface and take appropriate troubleshooting and handling measures based on the cause of the failure. If all checks pass, the backup package is deemed to have passed the security check and proceeds to the next step, where the BMC loads the configuration information from the backup package into the BIOS backup image.

[0120] This security verification step constructs a complete trusted verification system from three dimensions: time (validity period), version (model identification code and firmware version number), and device (device serial number). Together with the separate storage and pairing restoration mechanism of backup package and encryption key, it ensures the security and reliability of backup configuration recovery operation.

[0121] S104. After the security verification is passed, the BMC loads the configuration information in the backup package into the BIOS backup image.

[0122] It should be noted that the process of BMC loading configuration information into the BIOS backup image is not a simple data writing. Instead, it requires the BIOS to transmit the configuration information to the BIOS in a format that the BIOS can recognize through the communication channel between the BIOS and BMC. The BIOS then writes the configuration items one by one into its own configuration storage area.

[0123] Specifically, the BMC organizes the decrypted configuration information according to the BIOS configuration item format and encapsulates each item into an IPMI command. The IPMI command is a standard communication message format between the BMC and BIOS. In step S101, the BIOS notifies the BMC of configuration changes via IPMI commands; similarly, the BMC sends configuration recovery data to the BIOS via IPMI commands. The BMC sends IPMI commands containing the configuration item name and value to the BIOS one by one. After receiving the commands, the BIOS writes the corresponding configuration item to the configuration storage area of ​​the backup image. Once all configuration items have been written, the BIOS returns a write completion acknowledgment to the BMC, and the BMC confirms that the configuration information has been loaded.

[0124] It should be noted that when the BMC sends configuration items one by one, each IPMI command carries a sequence number. After writing each configuration item, the BIOS returns the corresponding sequence number to the BMC for confirmation. If the BMC does not receive a confirmation response for the corresponding sequence number within the preset timeout period after sending a command, it will retry sending the command. If the retry reaches the preset maximum number and still fails, the BMC will terminate the sending of subsequent configuration items, record the sequence numbers of successfully written configuration items in the audit log, and determine that the recovery is partially successful. In the BIOS backup image after a partially successful recovery, the configuration items that were successfully written use the configuration values ​​of the primary image, while the configuration items that were not successfully written retain the original configuration values ​​of the backup image. This design avoids the entire recovery process from being completely rolled back due to the failure of writing a single configuration item, balancing the recovery success rate and configuration integrity.

[0125] After loading, the BMC records an audit log for the recovery operation, including the recovery time, the version number of the backup package used, the recovery source, and the recovery result. This ensures that the BIOS standby image configuration is updated to the latest state consistent with that before the primary image failure. When the server boots from the standby image next time, the BIOS will read this configuration information and run according to the parameters last set by the user on the primary image, eliminating the need for manual reconfiguration of BIOS options by maintenance personnel, thus achieving automatic configuration recovery.

[0126] It should also be noted that if an exception occurs during the loading process, such as an interruption in communication between the BMC and BIOS, a write failure response from the BIOS, or a timeout, the BMC determines that the configuration loading has failed and records the failure event in the audit log. In this case, the BIOS backup image will continue to use its original default configuration information to complete the boot process, without affecting the server's normal boot procedure. This ensures that even if an exception occurs during the configuration recovery phase, the server's boot process will not be blocked while waiting for recovery to complete, achieving a fault-tolerant design of automatic synchronization upon successful recovery and fallback to the default configuration upon recovery failure.

[0127] It's also worth noting that BMC implements access control throughout the entire backup and recovery process. BMC maintains a hierarchical user access control table. Administrator users have backup package management permissions, including the manual creation, restoration, and deletion of backup packages, while regular users only have viewing permissions. When a user performs a manual backup, restoration, or deletion of a backup package through the BMC web management interface or IPMI commands, BMC first verifies the user's access level. If the user's permissions are insufficient, the operation is rejected and an audit log is recorded. This access control mechanism prevents unauthorized users from maliciously deleting or forcibly restoring backup packages, ensuring the security of backup package management operations.

[0128] The method provided in this embodiment encrypts BIOS configuration information to build a structured backup package, and stores the backup package and encryption key separately in two physically isolated storage areas: the BMC local eMMC and SPI ROM. It automatically triggers backup when configuration changes and automatically detects and restores when the primary image fails and switches to the backup image. This achieves encrypted synchronization and reliable recovery of BIOS primary and backup image configurations, and solves the problem in traditional BIOS dual-image schemes where business policies are lost and manual reconfiguration is required after the primary image fails and switches to the backup image due to the independent storage of configuration data. Specifically, by embedding the device serial number, model identification code, and firmware version number when building the backup package, the backup package is uniquely bound to the specific device that generated it, preventing the backup package from being illegally copied to other devices and then misused; by setting the backup validity period in the backup package and first verifying whether it is within the validity period during restoration, it is ensured that expired configurations will not be restored accidentally; by dynamically generating a unique encryption key for each backup package and using a one-time pad encryption mechanism, combined with the separate storage of the key and the backup package in physical location, the confidentiality of the backup configuration data is guaranteed; by performing three-dimensional security checks on the backup validity period, model version compatibility, and device serial number during restoration, the restoration is terminated and an alarm is triggered if any check fails, ensuring the reliability of the restoration operation; by storing the backup package in the BMC's local eMMC instead of relying on external network storage devices, the access to the backup package is not affected by the network link status, ensuring the reliable local execution of the configuration restoration process.

[0129] Example 2

[0130] Corresponding to the aforementioned embodiment of the BIOS dual-image configuration encryption synchronization and trusted recovery method, this application also provides an embodiment of the BIOS dual-image configuration encryption synchronization and trusted recovery device.

[0131] Figure 2 This is a schematic diagram of the second embodiment of the BIOS dual-image configuration encryption synchronization and trusted recovery device provided in this application. Please refer to... Figure 2The device provided in this embodiment includes a processing module 210, a management module 220, a verification module 230, and a loading module 240;

[0132] The processing module 210 is used to respond to changes in the configuration items of the BIOS master image. The BMC obtains the changed configuration information, encrypts the configuration information, and constructs a structured backup package by combining the device identification information and the timeliness control information.

[0133] The management module 220 is used to store the structured backup package in the local non-volatile storage area of ​​the BMC, and to perform index management on the backup package stored in the local non-volatile storage area.

[0134] The verification module 230 is used to read the backup package from the local non-volatile storage area and perform security verification on the backup package in response to detecting that the BIOS has switched from the BIOS primary image to the BIOS backup image for boot.

[0135] The loading module 240 is used to load the configuration information in the backup package into the BIOS backup image after the security verification is passed.

[0136] The apparatus of this embodiment can be used to perform... Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0137] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0138] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0139] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for encrypted synchronization and trusted recovery of BIOS dual-mirror configuration, characterized in that, The method is executed by the BMC and includes: In response to a change in the configuration items of the BIOS master image, the BIOS actively sends a configuration change notification and the changed configuration item information to the BMC via the Intelligent Platform Management Interface (IPMI) command. The BMC obtains the changed configuration information, encrypts the configuration information, and constructs a structured backup package by combining device identification information and timeliness control information. The BMC's security engine dynamically generates an encryption key, uses a symmetric encryption algorithm to encrypt the configuration information with the encryption key, stores the encryption key in a non-volatile storage partition physically isolated from the backup package storage area, and records the correspondence between the encryption key and the backup package in the backup package's index table. The BMC stores the structured backup package in its local non-volatile storage area and performs index management on the backup package stored in the local non-volatile storage area. In response to detecting a BIOS switch from the primary BIOS image to the backup BIOS image for booting, the BMC reads a backup package from the local non-volatile storage area and performs a security verification on the backup package; wherein, detecting a BIOS switch from the primary BIOS image to the backup BIOS image for booting includes: the BMC reads the register information of the CPLD through the I2C interface, and determines whether to switch from the primary BIOS image to the backup BIOS image based on the BIOS image boot source recorded in the CPLD register information; After the security verification is passed, the BMC loads the configuration information in the backup package into the BIOS backup image; Before encrypting the configuration information, the process includes: obtaining the current processor utilization and available memory capacity of the BMC; in response to the current processor utilization and available memory capacity of the BMC not meeting the preset backup execution conditions, calculating the gap value between the resources required to execute this backup task and the currently available resources, and determining the importance level of this configuration change; in response to the importance level being higher than a preset importance threshold, selecting tasks with timeliness requirements lower than a preset timeliness threshold from the BMC's task queue as suspendable tasks; based on the comparison result between the amount of resources that can be provided after the suspendable task is released and the gap value, if the amount of resources released by the suspendable task meets the gap value, then suspending part of the suspendable task and performing the backup; if the amount of resources released by the suspendable task does not meet the gap value, then storing this backup task in a delayed backup queue.

2. The method according to claim 1, characterized in that, The structured backup package constructed by combining device identification information and timeliness control information includes: Obtain the modified configuration information and encrypt the configuration information; The device's model identification code, firmware version number, and device serial number are identified as the device's identification information. The backup package is generated with a timestamp and a backup validity period, which serve as the timeliness control information. Calculate the hash message authentication code of the configuration information and the device identification information; The encrypted configuration information, the model identification code, the firmware version number, the device serial number, the generation timestamp, the backup validity period, and the hash message authentication code are combined into the structured backup package according to a preset field order.

3. The method according to claim 1, characterized in that, The step of storing the encryption key in a non-volatile storage partition that is physically isolated from the backup package storage area includes: During the generation of the backup package, the encryption key is written into a pre-divided independent partition in the serial peripheral interface flash memory (SPIROM) of the BMC. When restoring the backup package, the encryption key corresponding to the backup package is read from the independent partition of the SPI ROM according to the correspondence recorded in the index table of the backup package; The SPI ROM is connected to the BMC via an independent bus, and is physically located on a different hardware circuit than the embedded multimedia storage card containing the backup package.

4. The method according to claim 1, characterized in that, The indexing and management of backup packages stored in the local non-volatile storage area includes: Create an index table to record the image identifier, package version, and validity status fields for each backup package; When the available space in the local non-volatile storage area is insufficient to store the new backup package, the earlier backup packages are deleted in chronological order. When a backup package expires, the expired backup package will be deleted during the next configuration change.

5. The method according to claim 1, characterized in that, The local non-volatile storage area is an independent partition within the embedded multimedia storage card of the BMC, and the independent partition is isolated from the log storage area of ​​the BMC.

6. The method according to claim 1, characterized in that, The security verification of the backup package includes: Verify the backup validity period of the backup package to determine whether the backup package is within its validity period; Verify whether the model identification code and firmware version number in the backup package are compatible with the model identification code and firmware version number of the current device; Verify whether the device serial number in the backup package matches the serial number of the current device; If any verification item fails, the recovery process is terminated and an alarm message is output.

7. The method according to claim 1, characterized in that, The step of reading the backup package from the local non-volatile storage area includes: Based on the information recorded in the index table of the backup package, determine the encryption key identifier corresponding to the backup package; Based on the encryption key identifier, search for an encryption key that matches the encryption key identifier from the non-volatile storage partition of the BMC; The matched encryption key is read from the non-volatile storage partition to decrypt the encrypted configuration information in the backup package.

8. A BIOS dual-mirror configuration encryption synchronization and trusted recovery device, characterized in that, The device includes a processing module, a management module, a verification module, and a loading module; The processing module is used to respond to changes in the configuration items of the BIOS master image. The BIOS actively sends the configuration change notification and the changed configuration item information to the BMC through the Intelligent Platform Management Interface (IPMI) command. The BMC obtains the changed configuration information, encrypts the configuration information, and constructs a structured backup package by combining the device identification information and timeliness control information. The BMC's security engine dynamically generates an encryption key, uses a symmetric encryption algorithm to encrypt the configuration information with the encryption key, stores the encryption key in a non-volatile storage partition physically isolated from the backup package storage area, and records the correspondence between the encryption key and the backup package in the backup package's index table. The management module is used to store the structured backup package in the local non-volatile storage area of ​​the BMC, and to perform index management on the backup package stored in the local non-volatile storage area. The verification module is used to read the backup package from the local non-volatile storage area and perform security verification on the backup package in response to detecting that the BIOS has switched from the BIOS primary image to the BIOS backup image for booting. The loading module is used so that, after the security verification is passed, the BMC loads the configuration information in the backup package into the BIOS backup image; wherein, the detection of the BIOS switching from the BIOS primary image to the BIOS backup image includes: the BMC reads the register information of the CPLD through the I2C interface, and determines whether to switch from the BIOS primary image to the BIOS backup image based on the BIOS image boot source recorded in the CPLD register information; Before encrypting the configuration information, the process includes: obtaining the current processor utilization and available memory capacity of the BMC; in response to the current processor utilization and available memory capacity of the BMC not meeting the preset backup execution conditions, calculating the gap value between the resources required to execute this backup task and the currently available resources, and determining the importance level of this configuration change; in response to the importance level being higher than a preset importance threshold, selecting tasks with timeliness requirements lower than a preset timeliness threshold from the BMC's task queue as suspendable tasks; based on the comparison result between the amount of resources that can be provided after the suspendable task is released and the gap value, if the amount of resources released by the suspendable task meets the gap value, then suspending part of the suspendable task and performing the backup; if the amount of resources released by the suspendable task does not meet the gap value, then storing this backup task in a delayed backup queue.

Images