Configuration Recovery Method of Baseboard Management Controller and Baseboard Management Controller

Abstract

The present application discloses a configuration recovery method for a baseboard management controller and a baseboard management controller. Among them, a first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the execution of configuration recovery is controlled by the first operating system running in a trusted execution environment to improve the security of configuration recovery. The method includes: when the server accesses a first external device of a specified type, the first operating system verifies the first external device to ensure the legitimacy of the accessed device; if the first external device passes the verification, a recovery confirmation request is sent to the first external device via the second operating system; and when it is detected that a specified button is pressed, the baseboard management controller is configured and recovered using the first configuration information stored in the first external device. Since the configuration information is stored in an external device and the recovery is confirmed through a specific button, the risk of the configuration information being tampered with can be reduced, ensuring the security of configuration recovery.

Description

Technical Field

[0001] This application relates to the technical field of servers, and in particular, to a method for restoring the configuration of a baseboard management controller and a baseboard management controller. Background Art

[0002] In a server, a baseboard management controller is mainly used for remote management of the server. For example, it monitors the hardware status, restarts the system, upgrades the firmware, etc. When the baseboard management controller fails, the method for restoring the configuration of the baseboard management controller adopted in the related art is: using the configuration file stored internally in the baseboard management controller for configuration restoration.

[0003] However, the configuration file used for configuration restoration is easily tampered with by malware and replaced with a malicious version. Using the tampered configuration file for configuration restoration is likely to damage the baseboard management controller, thereby affecting the normal and stable operation of the server.

[0004] It can be seen that in the method for restoring the configuration of the baseboard management controller in the related art, there is a problem of poor security of the baseboard management controller caused by the easy tampering of the configuration file. Summary of the Invention

[0005] This application provides a method for restoring the configuration of a baseboard management controller and a baseboard management controller, so as to at least solve the problem of poor security of the baseboard management controller caused by the easy tampering of the configuration file in the method for restoring the configuration of the baseboard management controller in the related art.

[0006] According to one aspect of the embodiments of this application, this application provides a method for restoring the configuration of a baseboard management controller. A first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment; the method includes: when a first external device of a specified type is connected to the server where the baseboard management controller is located, verifying the first external device through the first operating system, and when the first external device passes the verification, sending a restoration confirmation request to the first external device via the second operating system, where the specified type is a device type for storing the configuration information of the baseboard management controller, and the restoration confirmation request is used to request confirmation of configuration restoration by pressing a specified button on the first external device; when it is detected that the specified button is pressed, obtaining first configuration information stored in the first external device through the first operating system via the second operating system, and using the first configuration information to control the second operating system to perform configuration restoration on the baseboard management controller.

[0007] According to another aspect of the embodiments of the present application, the present application further provides a baseboard management controller. A first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment. Among them, the first operating system is configured to verify a first external device of a specified type when the server where the baseboard management controller is located accesses the first external device of the specified type, and when the verification of the first external device is passed, send a recovery confirmation request to the first external device via the second operating system. The specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request to confirm the configuration recovery by pressing a specified button on the first external device. When it is detected that the specified button is pressed, obtain the first configuration information stored in the first external device via the second operating system, and use the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller. The second operating system is configured to send the recovery confirmation request to the first external device and perform configuration recovery on the baseboard management controller.

[0008] According to yet another aspect of the embodiments of the present application, the present application further provides a server, including: a baseboard management controller, where a first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment. Among them, the first operating system is configured to verify a first external device of a specified type when the server accesses the first external device of the specified type, and when the verification of the first external device is passed, send a recovery confirmation request to the first external device via the second operating system. The specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request to confirm the configuration recovery by pressing a specified button on the first external device. When it is detected that the specified button is pressed, obtain the first configuration information stored in the first external device via the second operating system, and use the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller. The second operating system is configured to send the recovery confirmation request to the first external device and perform configuration recovery on the baseboard management controller.

[0009] According to yet another aspect of the embodiments of the present application, an electronic device is further provided, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to execute the steps in any of the above method embodiments through the computer program.

[0010] According to still another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0011] According to still another aspect of the embodiments of the present application, there is provided a computer program product or a computer program. The computer program product or the computer program includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any one of the above method embodiments.

[0012] Through the present application, a first operating system and a second operating system are run on different hardware resources of a baseboard management controller. The execution of configuration restoration is controlled by the first operating system running in a trusted execution environment to improve the security of configuration restoration. When a server where the baseboard management controller is located accesses a first external device of a specified type (a device type for storing configuration information of the baseboard management controller), the first external device is verified by the first operating system to ensure the legality of the accessed device. When the first external device passes the verification, a restoration confirmation request is sent to the first external device via the second operating system to request confirmation of configuration restoration by pressing a specified button on the first external device. Confirming configuration restoration through a specific button on the external device can ensure that configuration restoration is performed under the participation of a human, reducing the possibility of malicious software illegally triggering configuration restoration. When it is detected that the specified button is pressed, the first configuration information stored in the first external device is obtained by the first operating system via the second operating system, and the first configuration information is used to control the second operating system to perform configuration restoration on the baseboard management controller. Since the configuration information is stored in an external device, the timing of the external device accessing the server can be controlled, thereby reducing the risk of the configuration information being tampered with. It is possible to solve the technical problem in the related art that the security of the baseboard management controller is poor due to the easy tampering of the configuration file in the configuration restoration method of the baseboard management controller, and achieve the technical effect of improving the security of the baseboard management controller. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] Figure 1Schematic diagram of an application scenario of a method for restoring the configuration of a baseboard management controller provided by an embodiment of the present application.

[0015] Figure 2 It is a flowchart of an optional method for restoring the configuration of a baseboard management controller according to an embodiment of the present application.

[0016] Figure 3 It is a system framework diagram of a baseboard management controller according to an embodiment of the present application.

[0017] Figure 4 It is a schematic flowchart of an optional process for manufacturing a one-key recovery USB key according to an embodiment of the present application.

[0018] Figure 5 It is a schematic flowchart of an optional one-key recovery of a USB key according to an embodiment of the present application.

[0019] Figure 6 It is a schematic block diagram of an optional baseboard management controller according to an embodiment of the present application.

[0020] Figure 7 It is a schematic block diagram of a computer system of an optional electronic device according to an embodiment of the present application. Detailed implementation manners

[0021] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0022] It should be noted that in the description of the present application, the terms "including", "comprising" or any other variant thereof are intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0023] To enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below in conjunction with the accompanying drawings and specific implementation manners.

[0024] According to one aspect of the embodiments of the present application, a method for restoring the configuration of a baseboard management controller is provided. Optionally, in the embodiments of the present application, the above method for restoring the configuration of a baseboard management controller may but is not limited to be applied to, for example Figure 1In the hardware environment including a server 102 (including a baseboard management controller 104), a configuration device 106, and an external device 108 as shown. The configuration device 106 can be connected to the server 102 through a network or a data cable. The external device 108 can be connected to the server 102 by directly inserting into an interface on the server 102, connecting to an interface on the server 102 via a data cable, etc. When the baseboard management controller 104 needs to perform configuration recovery, the configuration information stored on the external device 108 can be used to perform configuration recovery on the baseboard management controller 104.

[0025] The above network can include, but is not limited to, at least one of the following: a wired network, a wireless network. The above wired network can include, but is not limited to, at least one of the following: a wide area network, a metropolitan area network, a local area network. The above wireless network can include, but is not limited to, at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The server 102 can be, but is not limited to, a cloud server, a server cluster, or other server types. The configuration device 106 can be, but is not limited to, a PC (Personal Computer), a mobile phone, a tablet computer, etc. The external device 108 can include, but is not limited to, at least one of the following: a USB storage device (e.g., a USB flash drive), a USB key, etc.

[0026] The configuration recovery method of the baseboard management controller according to the embodiments of the present application can be executed by the baseboard management controller 104, or can be executed by the baseboard management controller 104 in combination with at least one of the configuration device 106 and the external device 108. Among them, the configuration method of the baseboard management controller according to the embodiments of the present application executed by the configuration device 106 can also be executed by a client installed thereon.

[0027] Taking the execution of the configuration recovery method of the baseboard management controller in this embodiment by the baseboard management controller 104 as an example, Figure 2 is a schematic flowchart of an optional baseboard management controller according to the embodiments of the present application, as Figure 2 shown, the process of this method can include steps S202 to S204.

[0028] Step S202, when a first external device of a specified type is connected to the server where the baseboard management controller is located, verify the first external device through a first operating system, and when the first external device is verified successfully, send a recovery confirmation request to the first external device via a second operating system, where the specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request to confirm the configuration recovery by pressing a specified button on the first external device.

[0029] Step S204: When it is detected that a specified button is pressed, obtain, via a second operating system by a first operating system, first configuration information stored in a first external device, and use the first configuration information to control the second operating system to perform configuration restoration on a baseboard management controller.

[0030] The configuration restoration method for the baseboard management controller in the embodiments of this application can be applied to the field of server technology and is applied to the scenario of performing configuration restoration on the baseboard management controller of a server. A server is the core infrastructure that supports the operation of various information systems and networks. In a server, a baseboard management controller (abbreviated as BMC) is a component responsible for monitoring and managing the hardware status of the server. It is usually integrated on the server motherboard and is mainly used for remote management of the server, such as monitoring the hardware status (monitoring the health status of the hardware through various sensors, such as temperature, voltage, fan speed, etc.), restarting the system (for example, remotely powering on and off), firmware upgrade, etc. The baseboard management controller plays a crucial role in ensuring the stable operation and performance of the server.

[0031] When a failure occurs in the baseboard management controller (or other situations where configuration restoration is required), it is necessary to configure the configuration file of the baseboard management controller. The configuration restoration method for the baseboard management controller adopted in the related art is: using the configuration file stored internally in the baseboard management controller for configuration restoration, mainly relying on mechanisms at the software level.

[0032] However, the above configuration restoration method for the baseboard management controller has insufficient security, and the restoration process is easily tampered with by malware, resulting in the configuration file used for configuration restoration being replaced with a malicious version. The configuration file is stored inside the baseboard management controller. After the baseboard management controller is rooted (illegally invaded), a malicious attacker can modify the configuration file or implant malicious code and then trigger configuration restoration, thereby damaging the baseboard management controller and further affecting the normal and stable operation of the server.

[0033] Moreover, the configuration restoration function of the baseboard management controller in the related art is usually implemented in the web (World Wide Web) front end, Redfish (a standardized protocol for server management), or IPMI (Intelligent Platform Management Interface) commands and depends on the network and cannot be used when the network is disconnected or attacked.

[0034] To at least partially solve the above problems, in this embodiment, the configuration information used to perform configuration recovery on the baseboard management controller is stored on an external device, and the timing of the external device accessing the server can be controlled, thereby reducing the risk of the configuration information being tampered with. Moreover, a first operating system and a second operating system are running on different hardware resources of the baseboard management controller. The first operating system runs in a trusted execution environment. The first operating system verifies the external device and performs configuration recovery in combination with a physical confirmation button, which can ensure that the configuration recovery is executed under manual supervision, reduce the possibility of malicious configuration recovery, and improve the security of the baseboard management controller.

[0035] The configuration recovery method of the baseboard management controller in this embodiment can be a one-key recovery solution. The user only needs to press a specific button or perform a simple operation to automatically perform configuration recovery on the baseboard management controller. In case of a failure of the baseboard management controller, a fast, accurate, and safe one-key recovery can ensure the stable operation of the server.

[0036] The baseboard management controller can have multiple hardware resources. For example, a processor, memory, peripherals, etc. The first operating system and the second operating system can run on different hardware resources, where the first operating system runs in a trusted execution environment (Trusted Execution Environment, abbreviated as TEE). The division of hardware resources can be achieved through a hardware mechanism. For example, certain registers, memory areas, peripherals, etc. of the processor are clearly divided into corresponding attributes to distinguish the operating system (Operating System, abbreviated as OS) to which the hardware resources belong.

[0037] It should be noted that considering the differences in the processor architectures adopted by the baseboard management controller and the different naming perspectives (for example, from the functional perspective, from the perspective of usage frequency, etc.), the first operating system can also be called a security operating system or a trusted operating system, and the second operating system can also be called a general operating system or a normal operating system, as long as it can satisfy that the two operate on different hardware resources and one of the operating systems runs in a viable execution environment.

[0038] A Trusted Execution Environment (TEE) is a combined hardware and software technology designed to provide a secure and isolated environment for applications running on a device. The TEE is designed to run transparently without interfering with applications and services in the Rich Execution Environment (REE), also known as the non-secure execution environment. If the processor, firmware, operating system configuration, and runtime detection all indicate the presence of TEE support, and there is clear secure storage, resource access, trusted applications, and access control, then it can be determined that the operating system is running in the Trusted Execution Environment.

[0039] Taking the Baseboard Management Controller (BMC) adopting the ARM (Advanced RISC Machines) processor architecture as an example, the ARM processor architecture is a RISC (Reduced Instruction Set Computing) processor that can be applied to mobile devices, embedded systems, and servers. For the configuration recovery of the BMC adopting the ARM processor architecture, it can rely on the ARM TrustZone technology to physically isolate the data to be protected, thus ensuring data security. TrustZone is a system-level security technology. Based on the ARM processor architecture, TrustZone divides the hardware resources of the entire system (such as chips, devices, etc., the BMC in this embodiment) into two worlds: the Secure World (corresponding to the first operating system) and the Non-Secure World (corresponding to the second operating system). This division is achieved through hardware mechanisms. For example, certain registers, memory regions, peripherals, etc. of the processor are clearly divided into secure or non-secure attributes. At the hardware level, the Secure World and the Non-Secure World have their own independent operating environments, including independent instruction set execution spaces, memory mappings, etc. It is like building two relatively independent "subsystems" within a BMC, and the isolation between them is very high. The Non-Secure World cannot directly access the resources of the Secure World unless through strictly defined security interfaces.

[0040] It should be noted that the baseboard management controller adopting the ARM processor architecture can utilize the multi-level execution environment of the ARM processor. For example, from EL0 (Event Level 0, unprivileged mode of the ARM CPU) to EL3 (Event Level 3, secure mode of the ARM CPU), operating systems with different security levels can be run. Among them, EL3 is the execution level with the highest privilege and is usually used to run security-related firmware. For example, ARM Trusted Firmware (abbreviated as ATF).In the ARM processor architecture, the Baseboard Management Controller (BMC) may but is not limited to include the following components: a series of hardware interfaces, such as I²C (Inter-Integrated Circuit), SPI (Serial Peripheral Interface), PCIe (Peripheral Component Interconnect Express), etc. Through these hardware interfaces, the BMC can communicate with other components of the server to monitor sensor data, control fans, communicate with the CPU, etc.; one or more ARM processor cores for running the management and monitoring software of the BMC. These cores can run in the non-secure world or the secure world, or both, in order to perform different tasks and meet security requirements; storage resources for storing firmware, configuration files, monitoring data, etc. The storage resources may but are not limited to include at least one of the following: non-volatile memory (such as SPI NOR Flash), RAM, and an OTP (One Time Programmable) area for secure storage; a network interface for the BMC to communicate with a remote management platform. The network interface allows administrators to remotely monitor the server status and perform management operations and may but is not limited to include at least one of the following: the IPMI (Intelligent Platform Management Interface) protocol or the Redfish API (Application Programming Interface); an operating environment that is divided into a secure part and a non-secure part. The secure operating system (i.e., the first operating system) is responsible for managing security-related tasks, such as key management, secure communication, and secure storage access. The non-secure operating system (i.e., the second operating system) is responsible for handling regular monitoring and management tasks. One implementation is to use Linux as the second operating system, while a secure environment based on TrustZone technology runs a small secure operating system or trusted applications; security mechanism integration. The BMC can utilize TrustZone technology to implement security mechanisms. For example, by running a key management module in the secure world, using system calls at the EL3 level to handle sensitive operations, and using dedicated GPIO (General-purpose input / output) pins for detecting and controlling the security status, such as detecting the pressing of a specified button.

[0041] Configuration information for performing configuration recovery on a baseboard management controller can be stored on a storage device of a specified type. For example, a USB (Universal Serial Bus) storage device. Correspondingly, the storage device of the specified type can be a USB flash drive. If the server is connected to a first external device of the specified type, that is, if the server detects that a first external device of the specified type is connected, the first operating system can initiate a configuration recovery verification process for the baseboard management controller to verify the first external device. For example, verify the legality and effectiveness of the first external device to improve the security of configuration recovery. The method of verifying the first external device can be to verify the verification information (such as device identification, device secret key, etc.) of the first external device. What can be verified are the format of the verification information, the content of the verification information, etc. This is not limited in this embodiment.

[0042] For example, taking the first external device as a USB flash drive, the configuration file for performing configuration recovery on the BMC is stored in the external USB flash drive, and its digital signature and device fingerprint (such as the unique serial number) are verified through the TEE to ensure that only an authorized USB flash drive can initiate the recovery.

[0043] If the first external device passes the verification, the first operating system can send a recovery confirmation request to the first external device via the second operating system to request confirmation of configuration recovery by pressing a specified button on the first external device. The recovery confirmation request is to request a physical confirmation from the user, that is, to require the user to manually press the specified button on the first external device to finally confirm the execution of the configuration recovery operation. In this way, the recovery confirmation adds an extra security layer and reduces the occurrence of unauthorized or malicious tampering. The specified button can be a button marked on the first external device, and its signal can only be detected by the first operating system. When the user presses the specified button, the first operating system can detect the signal triggered by the pressing of the specified button.

[0044] Optionally, in this embodiment, a one-key recovery solution can be used, adopting a secure trigger mechanism to trigger the recovery process through a physical button (i.e., the specified button) or a specific hardware signal. The signal is directly transmitted to the first operating system (such as the TrustZone secure world, i.e., TEE), bypassing the second operating system (ordinary operating system, i.e., REE) to avoid interception. Physically ensuring the security of one-key recovery, manual participation in confirmation is required, and this confirmation signal will not be attacked by an attacker even if the baseboard management controller is rooted.

[0045] When it is detected that a specified key is pressed, the first operating system can obtain the first configuration information stored in the first external device via the second operating system. The first configuration information refers to the configuration information stored on the first external device for configuring and restoring the baseboard management controller, and may include, but is not limited to, network settings, security policies, user-defined options, etc. These configuration information are usually stored in the first external device under the control of the first operating system during the initialization of the first external device.

[0046] For example, taking the first external device as a USB key, when the signal that the specified key on the USB key is pressed is detected by the secure OS, the secure OS can send a command to the general OS to request one-key configuration restoration. After receiving the command to request one-key configuration restoration sent by the secure OS, the general OS reads the configuration information stored in the USB key and transfers it to the secure OS.

[0047] The first operating system can use the first configuration information to control the second operating system to perform configuration restoration on the baseboard management controller. For the case where the first configuration information is encrypted configuration information, the first configuration information can be decrypted first. The decrypted first configuration information is used for performing configuration restoration on the baseboard management controller. Optionally, the first operating system can first verify the first configuration information to ensure its validity and reliability, and then transfer the verified first configuration information to the second operating system for configuration restoration.

[0048] In addition, for the case where it is not necessary to decrypt the first configuration information, after the second operating system reads the first configuration information from the first external device, it can directly use the first configuration information to perform configuration restoration on the baseboard management controller, or first verify the first configuration information and then use the verified first configuration information to perform configuration restoration on the baseboard management controller.

[0049] Through the embodiments provided in this application, a first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment; when a server where the baseboard management controller is located accesses a first external device of a specified type, the first external device is verified through the first operating system, and when the first external device passes the verification, a recovery confirmation request is sent to the first external device via the second operating system, where the specified type is a device type for storing configuration information of the baseboard management controller, and the recovery confirmation request is used to request to confirm configuration recovery by pressing a specified button on the first external device; when it is detected that the specified button is pressed, the first operating system obtains first configuration information stored in the first external device via the second operating system, and uses the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller, solving the problem in the related art that the configuration recovery method of the baseboard management controller has poor security of the baseboard management controller due to the configuration file being easily tampered with, and improving the security of the baseboard management controller.

[0050] In some exemplary embodiments, after sending the recovery confirmation request to the first external device via the second operating system, the above method further includes: accessing a specified port through the first operating system and determining whether a recovery confirmation signal is detected from the specified port.

[0051] In this embodiment, detecting that the specified button is pressed can be executed by the first operating system. Adopting a secure trigger mechanism, the recovery process is triggered by the specified button. Pressing the specified button triggers a recovery confirmation signal, and the signal is directly transmitted to the first operating system, bypassing the second operating system to avoid interception. Physically, the security of one-key recovery is guaranteed, and manual participation is required for confirmation, and this confirmation signal will not be attacked by attackers even if the baseboard management controller is rooted.

[0052] The recovery confirmation signal can be transmitted to the first operating system through a specified port. A port refers to a channel for data transmission and communication, and the specified port is a port that is stipulated to only allow the first operating system to access, for example, a GPIO port, etc. For the first operating system, after sending the recovery confirmation request to the first external device via the second operating system, the first operating system can access the specified port to detect whether a recovery confirmation signal is incoming from the specified port.

[0053] When the user receives a prompt for a recovery confirmation request, they can press the specified button to trigger the aforementioned recovery confirmation signal. The first external device can send the recovery confirmation signal to the specified port through a certain communication method (such as electrical signal transmission, etc.). The first operating system determines whether a recovery confirmation signal is detected by accessing the specified port. If the first operating system detects the recovery confirmation signal, it indicates that the user confirms to perform configuration recovery, and subsequent operations of reading configuration information and executing configuration recovery can be carried out.

[0054] For example, the one-key recovery module of the secure OS detects the pressing of the security button through the GPIO that can only be accessed by the secure OS, and sends a request to the BMC to request the one-key recovery configuration file.

[0055] According to this embodiment, by accessing the specified port through the first operating system to detect the recovery confirmation signal, the physical security of the signal can be ensured, attacks at the software level can be prevented, and physical isolation and security control of the recovery confirmation are achieved.

[0056] In some exemplary embodiments, verifying the first external device by the first operating system includes: receiving, by the first operating system, the first verification information stored in the first external device transmitted by the second operating system; verifying, by the first operating system, the first verification information using the specified secret key stored in the one-time programmable area, where the one-time programmable area only allows access by the first operating system.

[0057] When the second operating system detects the connection of the first external device, the second operating system can read the first verification information stored in the first external device and transmit the first verification information to the first operating system. For the first operating system, it can receive the first verification information stored in the first external device transmitted by the second operating system. The first verification information is the information used for device verification of the first external device, and it can include, but is not limited to, at least one of the following: digital signature, device secret key (also known as security secret key), device identifier, timestamp. The device identifier of the first external device is used to identify the first external device, and it can include, but is not limited to, at least one of the following: device model, serial number (abbreviated as SN), device name. In this embodiment, no specific limitation is imposed on the first verification information.

[0058] Then, the first operating system can use the stored specified secret key to verify the first verification information received from the first external device. The verification process matches the information type of the first verification information, and can include, but is not limited to: decrypting the first verification information, checking the digital signature, or comparing the serial number of the first external device, etc., to confirm the legitimacy of the first external device and the non-tampered state of the data.

[0059] The specified key can be a key used for configuration recovery of the baseboard management controller. For the case where the verification information of an external device includes a device key, the specified key can be a seed key for generating the device key of an authorized device, and the authorized device is a device that allows configuration recovery of the baseboard management controller. The specified key can be the key of the SFS (Safe FileSystem). The safe file system can include functions such as data encryption, access control, permission management, logging, and auditing to protect the data stored on it from unauthorized access, tampering, or leakage. For a baseboard management controller adopting the ARM processor architecture, SFS refers to a file system that uses TrustZone technology for encryption and security verification, and is used to store and protect sensitive data such as configuration files and keys used in the BMC configuration recovery process. The design of this file system can ensure the integrity and confidentiality of data. Even if the ordinary operating system of the baseboard management controller is attacked, the data stored in the SFS can remain secure and unaffected.

[0060] The specified key can be stored in any storage area accessible to the first operating system. To avoid the specified key being maliciously modified, the specified key can be stored in a one-time programmable area. The one-time programmable area is a non-volatile storage area that can only be written once and is commonly used to store critical security parameters or keys. In this embodiment, the specified key is written in the one-time programmable area and only the first operating system is allowed to access it. It can be understood that even if the second operating system or any other software attempts to access it, they cannot read or modify the data therein.

[0061] Taking the first external device as a USB key and the first verification information as a security key as an example, when the one-key recovery process of the ordinary OS detects the access of the USB key, it obtains the security key of the USB key from the USB key and initiates a one-key recovery request, and transfers the security key of the USB key to the security OS. After the one-key recovery module of the security OS detects the one-key recovery request initiated by the ordinary OS, it verifies the security key of the USB key through the key stored in the OTP. If the verification passes, it sends a one-key recovery confirmation request to the ordinary OS (an example of the recovery confirmation request). After receiving the one-key recovery confirmation request from the security OS, the ordinary OS prompts the user to press the one-key recovery security button of the USB key (an example of the specified button).

[0062] Through this embodiment, by using the key stored in the one-time programmable area to verify the verification information of the external device, the credibility of the device is ensured, the recovery operation triggered by malicious devices is avoided, and the controllability and security of the recovery process are enhanced.

[0063] In some exemplary embodiments, the specified key may be a key pre-set for the baseboard management controller (independent of the authorized device), or may be generated based on the device identifier and random number of the authorized device. Compared with the solution of pre-setting the key, the key generated based on the device identifier and random number of the authorized device has higher flexibility and relevance, and more diverse verification methods can be adopted. Among them, the authorized device is a device that allows configuration restoration of the baseboard management controller, and its device type is a specified type.

[0064] Correspondingly, before receiving the first verification information stored in the first external device transmitted by the second operating system through the first operating system, the above method further includes: when the server accesses the second external device and configures the second external device as an authorized device, querying the one-time programmable area through the first operating system; when no data is written in the one-time programmable area, obtaining the device identifier of the second external device through the first operating system via the second operating system, generating a specified key based on the device identifier and random number of the second external device, and writing the generated specified key into the one-time programmable area.

[0065] In this embodiment, the user can connect the second access device to the server and trigger the configuration of the second external device as an authorized device by pressing a specific button or button combination on the second access device, or by performing a specific operation on the configuration interface of the configuration device. For the baseboard management controller, when the server accesses the second external device and configures the second external device as an authorized device, the second operating system can detect the information of the access of the second external device and feedback the information to the first operating system. After receiving the information transmitted by the second operating system, the first operating system can query the one-time programmable area. It should be noted that the second external device may be a USB storage device (such as a USB flash drive) or other devices that can be used for configuration restoration of the baseboard management controller, etc., and no specific limitation is made here.

[0066] If no device has been configured as an authorized device before, the one-time programmable area has no data written, and the first operating system does not query data from the one-time programmable area. In this case, it can request the device identifier of the second external device through the second operating system; then, generate a specified key based on the device identifier and random number of the second external device, and write the generated specified key into the one-time programmable area.

[0067] To improve the efficiency of information processing, when a second external device is connected to the server and the second external device is configured as an authorized device, the first operating system can receive the device identifier of the second external device transmitted by the second operating system; and in response to the received device identifier, perform an operation to query the one-time programmable area. When no data is written in the one-time programmable area, a specified secret key is generated according to the device identifier of the second external device and a random number.

[0068] Taking the example of using a USB flash drive to make a one-key recovery USB key, when the server is connected to the USB flash drive and uses the connected USB flash drive to make a one-key recovery USB key, the one-key recovery module of the security OS queries whether there is data written in the OTP. If no data is written, it means that the one-key recovery USB key has not been made. In this case, the security OS can request the device identifier of the USB flash drive through the general OS for generating a secret key to be written into the OTP, ensuring that only one USB key can be used for one machine.

[0069] The general OS can obtain the device identifier of the USB flash drive and send the obtained device identifier to the security OS. The one-key recovery module of the security OS generates the secret key of the secure SFS according to the device identifier of the USB flash drive and a random number.

[0070] Through this embodiment, when configuring an authorized device, a secret key is generated by combining the device identifier and a random number and stored in the OTP, which can ensure that there is a unique secret key in the OTP of the baseboard management controller, strengthen the device authorization management, realize the unique authorization and secret key generation of the device, and prevent the access of unauthorized devices.

[0071] In some exemplary embodiments, after generating the specified secret key according to the device identifier of the second external device and a random number, the above method further includes: using the specified secret key by the first operating system to encrypt the device identifier of the second external device and the current timestamp to obtain second verification information, and writing the second verification information as the device secret key of the second external device into the second external device for storage via the second operating system.

[0072] In this embodiment, the first operating system can use the specified secret key to encrypt the device identifier of the second external device to obtain second verification information, transmit the second verification information to the second operating system, and the second operating system writes the second verification information as the device secret key of the second external device into the second external device. The second external device can store the second verification information, and the stored second verification information can be used in the subsequent process of configuration recovery.

[0073] To ensure the integrity and traceability of the secret key, the device identifier and the current timestamp of the second external device can be encrypted using the specified secret key to obtain the aforementioned second verification information. The current timestamp can be the timestamp when the second external device transmits the device identifier to the first operating system, the timestamp when the specified secret key is generated, or other timestamps. Here, the timestamp can record a specific time, and the timestamp can be a number or a string containing information such as year, month, day, and second, or other forms, which are not limited here.

[0074] Taking the second external device as a USB flash drive as an example, the secure OS generates encrypted data using the secret key of the secure SFS for the device identifier and time of the current USB flash drive as the unique secure secret key of the USB flash drive, and returns it to the ordinary OS. The ordinary OS writes the obtained encrypted data into the USB flash drive and prompts the user that this secret key cannot be restored to the configuration with one key if it is lost.

[0075] Through this embodiment, by generating a device secret key by encrypting the device identifier and the timestamp, the integrity and traceability of the secret key can be ensured. Even if the device is tampered with, the validity of the device secret key can be judged through the timestamp.

[0076] In some exemplary embodiments, after generating the specified secret key according to the device identifier and the random number of the second external device, the method further includes:

[0077] Receiving, by the first operating system, the second configuration information transmitted by the second operating system, encrypting the second configuration information using the specified secret key, and writing the encrypted second configuration information into the second external device via the second operating system for storage, where the second configuration information is the configuration information of the baseboard management controller at the first moment.

[0078] In the related art, the configuration file used for configuring and restoring the baseboard management controller is stored in the internal storage of the device and is generally not encrypted, which may be invalid due to storage damage or physical access by an attacker. Therefore, the storage medium of the configuration file has security risks. Moreover, configuring and restoring the baseboard management controller directly restores the factory settings, and if the relevant configuration has been modified by the user in the middle, it will be lost when the configuration is restored again.

[0079] For this reason, in this embodiment, the configuration information of the baseboard management controller can be encrypted using the specified secret key, and the encrypted data (encrypted configuration information) can be written into the authorized device for storage. Since the configuration information is encrypted, the security of the configuration information can be improved; moreover, the configuration information is the configuration information at a certain moment, rather than the configuration information at the factory, so it is possible to support restoring to the configured version and improve the flexibility of configuration restoration.

[0080] After generating the specified secret key, the first operating system can obtain the configuration information of the baseboard management controller (or the configuration information of the server, related to the baseboard management controller) from the second operating system to obtain the second configuration information. Subsequently, the second configuration information is encrypted using the specified secret key, and the encrypted second configuration information is transmitted to the second operating system. After receiving the encrypted second configuration information returned by the first operating system, the second operating system writes the encrypted second configuration information into the second external device for storage.

[0081] Taking the second external device as a USB flash drive as an example, the ordinary OS transfers the configuration information of the current server to the secure OS for encryption. The secure OS encrypts the configuration data transferred by the ordinary OS using the secret key of the secure SFS and sends it back to the ordinary OS. The ordinary OS writes the encrypted configuration file returned by the secure OS into the USB flash drive.

[0082] Through this embodiment, encrypting the configuration information using the specified secret key allows users to save the configuration state at different time points, enhancing the flexibility and security of configuration recovery and protecting the user-defined configuration from being reset.

[0083] In some exemplary embodiments, obtaining the device identifier of the second external device by the first operating system via the second operating system includes: obtaining the device model of the second external device and the serial number of the second external device by the first operating system via the second operating system.

[0084] In this embodiment, at least one of the device model and the serial number can be used as the device identifier. To improve the security level of the specified secret key and the device secret key (generating with two pieces of information is more secure than generating with a single piece of information), the device model and the serial number can be used as the device identifier to generate the specified secret key and the device secret key. Correspondingly, the second operating system can obtain the device model of the second external device and the serial number of the second external device, and the second operating system transmits the information of the device model of the second external device to the first operating system. The device identifier of the second external device includes the device model of the second external device and the serial number of the second external device.

[0085] Taking the second external device as a USB flash drive as an example, the ordinary OS obtains information such as the model and SN of the USB flash drive and sends it to the secure OS. The one-key recovery module of the secure OS generates the secret key of the secure SFS (secure file system) based on the model and SN of the USB flash drive and a random number, and generates encrypted data using this secret key for the current model, SN, and time of the USB flash drive as the unique secure secret key of the USB flash drive, and returns it to the ordinary OS.

[0086] Through this embodiment, by using the device model and the serial number as the device identifier to generate the specified secret key and the device secret key, the comprehensiveness and uniqueness of the device identifier can be ensured, enhancing the accuracy of device verification.

[0087] In some exemplary embodiments, the above method further includes: when the server accesses a second external device, receiving, by a second operating system, a configuration instruction sent by a first configuration device, where the configuration instruction is used to instruct to configure the second external device as an authorized device; sending, by the second operating system, a query request to the first operating system, where the query request is used to request to query whether an authorized device has been configured for the baseboard management controller. Querying the one-time programmable area is performed after receiving the query request.

[0088] Configuring the first external device as an authorized device may be triggered by operating the second external device. Considering the limited functions of the second external device itself, the possibilities of related operations are restricted. For this reason, configuring the first external device as an authorized device can be triggered by an additional configuration device. The connection manner between the configuration device and the server may be as Figure 1 shown, which has been described before and will not be elaborated here.

[0089] In this embodiment, the user can connect the second external device to the server and send a configuration instruction to the server through a first configuration device (which has established a communication connection with the server) to instruct to configure the second external device as an authorized device. Here, what the configuration instruction indicates may be to configure the currently connected external device as an authorized device. Since the currently connected device is the second external device, therefore, what the configuration instruction actually indicates is to configure the second external device as an authorized device.

[0090] The second operating system can receive the above configuration instruction. In response to the received configuration instruction, the second operating system sends a query request to the first operating system. The purpose of this query request is to query whether an authorized device has been configured for the baseboard management controller. The first operating system queries the one-time programmable area after receiving the query request.

[0091] For example, the user connects a USB storage device to the server and sends a configuration instruction through management software on a computer to instruct to configure the USB storage device of the server as a one-key recovery USB token. The general OS receives the configuration instruction and, in response to the received configuration instruction, sends a query request to the secure OS. The secure OS queries the OTP to determine whether a one-key recovery USB token has been made.

[0092] Through this embodiment, by sending a configuration instruction through a configuration device to trigger configuring the connected external device as an authorized device, and after the second operating system receives the configuration instruction, triggering the first operating system to query whether there is an existing authorized device, it is possible to avoid repeated configuration and enhance the standardization of configuration management.

[0093] In some exemplary embodiments, before receiving the configuration instruction sent by the first configuration device through the second operating system, the above method further includes: displaying an interaction interface of the baseboard management controller on the display screen of the first configuration device, where the interaction interface is an interface for configuring authorized devices for the baseboard management controller, and a configuration trigger control is displayed on the interaction interface; in response to a trigger operation performed on the configuration trigger control, sending a configuration instruction to the baseboard management controller.

[0094] In this embodiment, the authorized device configuration can be performed through the interaction interface of the baseboard management controller (for example, the BMC web human-machine interaction interface). The interaction interface is an interface for configuring authorized devices for the baseboard management controller, and a configuration trigger control (which can be a button, an icon, or other interactive controls) can be displayed on the interaction interface. Through this configuration trigger control, the authorized device configuration can be triggered.

[0095] The user can run management software (which can be application software, a mini-program, or a web page) on the first configuration device, and through certain operations, make the above-mentioned interaction interface of the baseboard management controller be displayed on the display screen of the first configuration device. By clicking, double-clicking, long-pressing, or other trigger operations, the management software can be triggered to send the above-mentioned configuration instruction to the server.

[0096] For example, after the BMC is configured, the one-key recovery U disk can be initialized. The server accesses the USB disk, and clicks the button for making the one-key recovery U disk on the BMC web human-machine interaction interface to trigger making the accessed USB disk into a one-key recovery U disk.

[0097] Through this embodiment, the device authorization configuration is realized through the configuration trigger control, which simplifies the user operation, improves the controllability of the configuration process and the user experience, and enhances the friendliness of the human-machine interaction.

[0098] In some exemplary embodiments, after querying the one-time programmable area through the first operating system, the above method further includes: in the case where a specified secret key has been written in the one-time programmable area, obtaining, through the first operating system via the second operating system, the second verification information stored in the second external device, and verifying the second verification information using the specified secret key; in the case where the second verification information is verified successfully, receiving, through the first operating system, the third configuration information transmitted by the second operating system, encrypting the third configuration information using the specified secret key, and writing the encrypted third configuration information into the second external device for storage via the second operating system.

[0099] If only allowing the configuration information to be saved when a certain external device is configured as an authorized device, then the configuration information stored in the authorized device is the configuration information at a certain moment. Although it can save the configuration before a certain moment compared with the way of restoring the factory settings, once the configuration information is saved, the configuration information will be lost after that moment, and the process of reconfiguring the information is complex and prone to loss. For this reason, in this embodiment, it is allowed to update the configuration information saved in the authorized device, and the update of the configuration information can be achieved by reconfiguring the device.

[0100] Correspondingly, if a specified secret key has been written in the one-time programmable area, the second operating system can obtain the second verification information stored in the second external device and transmit the obtained second verification information to the first operating system. Here, the second verification information can be obtained by the first operating system using the specified secret key to encrypt the device identifier of the second external device and a certain timestamp (for example, the timestamp at the encryption moment or the timestamp at any of the aforementioned possible moments). The first operating system can use the specified secret key in the one-time programmable area to verify the obtained second verification information, and the method of verifying the second verification information using the specified secret key is the same as or similar to the method of verifying the first verification information using the specified secret key.

[0101] Optionally, the second verification information and the device identifier of the second external device can be obtained together. In this case, the first operating system can obtain the second verification information stored in the second external device and the device identifier of the second external device (for example, the aforementioned device model and serial number, etc.) via the second operating system. The device identifier of the second external device can be used to verify the second verification information or perform other processing operations.

[0102] As an optional implementation manner, in the case where the server accesses the second external device and configures the second external device as an authorized device, when the second external device stores the second verification information, the first operating system receives the second verification information (or the second verification information and the device identifier of the second external device) transmitted by the first operating system and queries the one-time programmable area; if no data is written in the one-time programmable area, at this time, the second verification information can be ignored, or, in order to improve the utilization rate and flexibility of device utilization, verification information can be regenerated for the second external device based on the device identifier of the second external device, and the regenerated verification information is sent to the second external device for storage via the second operating system.

[0103] As another alternative embodiment, when the server accesses the second external device and configures the second external device as an authorized device, and when the second external device stores second verification information, the first operating system receives the second verification information (or the second verification information and the device identifier of the second external device) transmitted by the first operating system, and queries the one-time programmable area. If the specified secret key has been written in the one-time programmable area, the specified secret key can be used to verify the second verification information. For the case of obtaining both the second verification information and the device identifier of the second external device at the same time, one way to verify the second verification information can be: encrypt the device identifier of the second external device using the specified secret key and compare whether the encryption result is consistent with the second verification information. It can also be other verification methods, which are not limited in this embodiment.

[0104] If the second verification information passes the verification, it indicates that the second external device is an authorized device (i.e., an authorized device). At this time, the update operation of the configuration information stored in the authorized device can be executed. The first operating system can receive the third configuration information transmitted by the second operating system. That is, the third configuration information is the configuration information of the baseboard management controller at the second moment. The second moment can be the time point after the system has performed operations (such as updates, adjustments, etc.). The second moment is different from the aforementioned first moment. Then, the first operating system encrypts the third configuration information using the specified secret key, and then transmits the encrypted third configuration information to the second operating system. The second operating system then writes the encrypted third configuration information into the second external device for storage.

[0105] Through this embodiment, after verifying the verification information (such as the device secret key) of the external device, the configuration information stored in the external device is updated, which can improve the flexibility of configuration information storage and the security of configuration information update.

[0106] In some exemplary embodiments, before obtaining the second verification information stored in the second external device through the first operating system via the second operating system, the above method further includes: sending a reconfiguration confirmation request from the first operating system via the second operating system to the second configuration device; and in the case of receiving the reconfiguration confirmation signal returned by the second configuration device in response to the reconfiguration confirmation request, sending an information acquisition request from the first operating system via the second operating system to the second external device to request to obtain the verification information stored in the second external device.

[0107] Obtaining the second verification information stored in the second external device can be performed automatically. That is, when a specified secret key has been written in the one-time programmable area, the first operating system directly obtains the second verification information stored in the second external device via the second operating system. To improve the reliability of the configuration information update, obtaining the second verification information stored in the second external device can be performed in response to a received reconfiguration confirmation signal, where the reconfiguration confirmation signal is used to indicate confirmation of reconfiguring the configuration information of the second external device storage.

[0108] Correspondingly, before the first operating system obtains the second verification information stored in the second external device via the second operating system, the first operating system can send a reconfiguration confirmation request to the second configuration device through the second operating system to request confirmation of reconfiguring the configuration information of the second external device storage. The second configuration device can be a device that triggers the configuration of the second external device as an authorized device, such as a computer, a console, etc. It can be understood that sending the reconfiguration confirmation request is to confirm whether to perform subsequent operations, that is, to reconfigure the configuration information of the second external device storage.

[0109] The user can trigger, for example, through a physical button (such as the aforementioned specified button) on the second external device or other means, thereby triggering a reconfiguration confirmation signal to confirm the reconfiguration of the verification information stored in the second external device. Similar to the foregoing embodiments, the first operating system can detect the reconfiguration confirmation signal in a manner similar to that of detecting the recovery confirmation signal (for example, the first operating system can access a specified port and determine whether the reconfiguration confirmation signal is detected from the specified port).

[0110] After receiving the reconfiguration confirmation signal returned by the second configuration device in response to the reconfiguration confirmation request, the first operating system can send an information acquisition request to the second external device via the second operating system to request to acquire the verification information stored in the second external device. If the first operating system does not receive the reconfiguration confirmation signal returned by the second configuration device in response to the reconfiguration confirmation request within a certain period of time, it can be considered that the user does not wish to perform the reconfiguration of the configuration information, and subsequent processing can be skipped, thereby reducing unnecessary operations.

[0111] For example, after initializing the one-key recovery USB key, the USB key can be remade. The server accesses the USB flash drive and clicks the button to make the one-key recovery USB key on the BMC web human-machine interaction interface. The one-key recovery module of the secure OS queries whether the OTP has been written. If the secret key has been written, it returns that the USB key has been made and notifies the general OS to request the secret key of the USB flash drive (or the model, SN, and secret key of the USB flash drive). After verifying that the USB key is legal, the configuration data transmitted by the general OS is encrypted using the secret key of the secure SFS written to the OTP and then returned to the general OS. The general OS writes the encrypted configuration data returned by the secure OS to the USB flash drive and prompts the user that this data cannot be changed or deleted (here, cannot be changed or deleted means that the user cannot modify or delete it by themselves).

[0112] Through this embodiment, by interacting with the configuration device to reconfigure the configuration information after obtaining the reconfiguration confirmation signal, human errors can be reduced, and the accuracy and efficiency of the reconfiguration of the configuration information can be improved.

[0113] In some exemplary embodiments, there may be one or more ways to generate the specified secret key. Random numbers or pseudo-random numbers can be used as the specified secret key, or the device identifier of the authorized device (the authorized device is a device that allows the configuration recovery of the baseboard management controller, and its device type is the specified type), or the device identifier of the authorized device and other information (such as random numbers, pseudo-random numbers, timestamps, etc.) are hashed to obtain the specified secret key. Hashing is an algorithm that converts data of any length into a fixed-length value (hash value). The hash value is unique, and even if the data changes slightly, the hash value will be different. In this case, the specified secret key includes the first hash value obtained by hashing the device identifier of the authorized device.

[0114] For example, the general OS can obtain information such as the model and SN of the USB flash drive and send it to the secure OS. The one-key recovery module of the secure OS generates a hash value as the secret key of the secure SFS based on the model, SN, and random number of the USB flash drive.

[0115] Optionally, in this embodiment, verifying the first verification information using the specified secret key stored in the one-time programmable area by the first operating system includes: decrypting the first verification information using the specified secret key by the first operating system to obtain the decrypted verification information, where the decrypted verification information includes a device identifier part; hashing the device identifier part by the first operating system and comparing the obtained second hash value with the first hash value to verify the device identifier part.

[0116] To verify the first verification information, the first operating system may decrypt the first verification information using a specified secret key to obtain the decrypted verification information. The method of decrypting the first verification information corresponds to the method of encrypting to obtain the verification information, and different encryption and decryption methods can be selected according to usage requirements, which are not limited in this embodiment.

[0117] The obtained decrypted verification information includes a device identification part, which can be verified. There are various ways to verify the device identification part. For example, based on a set data format, format verification can be performed on the device identification part. If the format verification passes, it is considered that the device identification part verification passes. To improve the reliability of data verification, the device identification part can be hashed, and the obtained second hash value and the first hash value can be compared to verify the device identification part. If the second hash value is the same as the first hash value, it is considered that the device identification part verification passes; if the second hash value is different from the first hash value, it is considered that the device identification part verification fails.

[0118] In this embodiment, using the hash value of the device identification to verify the device identification ensures the irreversibility of the verification process and the immutability of the device identification, enhancing the reliability and security of the verification.

[0119] In some exemplary embodiments, to improve the reliability of the verification information, the verification information (device identification) of the authorized device can be generated by combining the device identification and the timestamp. In this case, the decrypted verification information also includes a timestamp part. Here, the timestamp can be a marker recording the information generation or operation sending time point, including information such as year, month, day, and hour.

[0120] For example, the secure OS can generate encrypted data using the secret key in the OTP with the current U disk model, SN, and time as the unique secure secret key of the U disk and return it to the ordinary OS. The ordinary OS writes the obtained encrypted data into the U disk and can also prompt the user that this secret key cannot be restored with one key if it is lost.

[0121] Correspondingly, verifying the first verification information by the first operating system using the specified secret key stored in the one-time programmable area further includes: parsing the timestamp part by the first operating system according to the specified time format to verify the timestamp part.

[0122] For the timestamp part, the first operating system can parse the timestamp part according to a pre-set specified time format. The specified time format can be a standard format specified by the system in advance, used to standardize the representation and interpretation methods of timestamps. For example, the timestamp may be stored in the format of "year-month-day hour:minute:second", and the first operating system can parse the content of the timestamp part according to this format.

[0123] The first operating system verifies the parsed timestamp. The verification method can include, but is not limited to, checking whether the timestamp is within a reasonable time range, such as within the valid time interval set by the system, or whether the difference from the current system time is within an acceptable error range, etc.

[0124] Through this embodiment, the timestamp is parsed and verified, preventing the timestamp from being tampered with, ensuring the timeliness of the device verification information, and protecting the configuration recovery mechanism from being exploited by outdated or malicious information.

[0125] In some exemplary embodiments, the first configuration information is used to control the second operating system to perform configuration recovery on the baseboard management controller, including: decrypting the first configuration information using a specified key to obtain the decrypted configuration information; and sending the decrypted configuration information back to the second operating system for the second operating system to use the decrypted configuration information to perform configuration recovery on the baseboard management controller.

[0126] To ensure the security and reliability of the configuration information, the first configuration information can be encrypted configuration information. In this case, the first operating system can decrypt the first configuration information using a specified key. Similar to the foregoing embodiments, the specified key is stored in the one-time programmable area and only the first operating system is allowed to access it. The first operating system can send the decrypted configuration information back to the second operating system, and the second operating system can use the decrypted configuration information to perform configuration recovery on the baseboard management controller. For example, the decrypted configuration information can include the network configuration parameters of the baseboard management controller (such as IP address, subnet mask, etc.), hardware monitoring transmissions (such as temperature threshold, fan speed control transmission, etc.), and the second operating system can reconfigure the corresponding modules and functions of the baseboard management controller according to these configuration information, so that the baseboard management controller is restored to the configuration state expected by the user.

[0127] For example, after receiving the command to restore the configuration with one key sent by the secure OS, the ordinary OS reads the current encrypted configuration information from the USB flash drive and transfers it to the secure OS for decryption. The secure OS decrypts the encrypted configuration information transferred by the ordinary OS using the key written to the secure SFS of the OTP and sends it back to the ordinary OS. After receiving the decrypted configuration information transferred by the secure OS, the ordinary OS configures the BMC to complete the one-key system recovery function.

[0128] It should be noted that for the case where the first configuration information is unencrypted configuration information, when it is detected that a specified button is pressed, the first operating system may send a configuration restoration instruction to the second operating system. The second operating system may obtain the first configuration information from the first external device and directly use the first configuration information to perform configuration restoration on the baseboard management controller; or, when it is detected that the specified button is pressed, the first operating system may obtain the first configuration information stored in the first external device via the second operating system, verify the first configuration information, and after the verification passes, use the first configuration information to control the second operating system to perform configuration restoration on the baseboard management controller. If the second operating system has a function of verifying configuration information, the second operating system may also obtain the first configuration information from the first external device, verify the first configuration information, and after the verification passes, use the first configuration information to perform configuration restoration on the baseboard management controller.

[0129] Through this embodiment, decrypting the configuration information in the first operating system ensures the security of the decryption process, and passing the decrypted configuration information to the second operating system for configuration restoration realizes the controllable use of the secure configuration information.

[0130] In some exemplary embodiments, before the first operating system verifies the first external device, the above method further includes: the second operating system initiating a call to the secure monitoring mode to the first operating system and passing the first verification information to the first operating system.

[0131] The isolation level between the first operating system and the second operating system is relatively high. The secure monitoring mode can be used as a bridge connecting the two (the secure world and the non-secure world). When it is necessary to switch between the two operating systems (for example, calling the functions or performing data interaction in the secure world from the non-secure world), the first operating system can enter the secure monitoring mode. In this mode, the system will perform a series of security checks and state transition operations to ensure the security of data and operations. For example, checking whether the call request conforms to the pre-set security policy and correctly switching and protecting the involved hardware resources (such as the register status).

[0132] In this embodiment, when the server accesses the first external device, the second operating system may initiate a call to the secure monitoring mode to the first operating system. Taking the baseboard management controller with the ARM processor architecture as an example, when the ordinary OS calls the kernel state, the kernel state enters the secure OS through an SMC (Supervisor Mode Call, a program running in the ordinary world requests a security service) interrupt to call the ATF (ARM Trusted Firmware).

[0133] When interacting with the first external device, the second operating system can obtain the first verification information, which is used to verify the legality and security of the first external device. When initiating a security monitoring mode call to the first operating system, the second operating system can transfer the first verification information to the first operating system so that the first operating system can use the first verification information to verify the first external device in the security monitoring mode.

[0134] Through this embodiment, by initiating a security monitoring mode call through the second operating system, the secure information exchange with the first operating system is realized, avoiding the risk of information leakage during the transmission process and enhancing the security of information exchange.

[0135] The following explains the configuration recovery method of the baseboard management controller in the embodiments of the present application in combination with optional examples. In this optional example, the baseboard management controller is a BMC adopting the ARM processor architecture, the first operating system is a secure OS corresponding to the Secure World, the second operating system is a normal OS corresponding to the Normal World (ordinary world), the designated port is a GPIO port, the authorized device is a USB key (one-key recovery USB key), the first external device and the second external device are USB flash drives (the USB key is the USB flash drive that is allowed to perform configuration recovery on the BMC after authorization), and the designated button is the one-key recovery confirmation button.

[0136] The system framework diagram of the BMC can be as Figure 3As shown in the figure, based on the partitioning of hardware resources, the Baseboard Management Controller (BMC) can be divided into the normal world and the secure world. A USB flash drive (U shield) can be connected to the server through a USB interface (i.e., added to the normal world). The normal world corresponds to unprotected hardware resources, which may include: a one-key recovery monitoring module running at the EL0 application layer, used to monitor the access of the U shield, trigger the recovery process, and interact with the user for confirmation; the Baseboard Management Controller operating system (which can be a Linux system) running at the EL1 system layer, i.e., the normal OS. Among them, communication can be carried out between the EL0 application layer and the EL1 system layer through SVC (Supervisor Call, system call into the kernel space) interrupts. Interaction between the normal world and the secure world can be achieved through the EL3 ATF layer. The EL3 ATF layer is the security layer of the ARM chip, which provides isolation and security control for the normal world and the secure world at the physical level, and at the same time provides a secure communication channel for both. The secure world corresponds to protected hardware resources, which may include: a trusted operating system (Trusted OS), i.e., the secure OS, and trusted applications (Trusted App, abbreviated as TA), such as a one-key recovery module and a key management module. Among them, the one-key recovery module is used to control the process of one-key recovery, and the key management module can access the one-time programmable area (OTP) to manage the keys stored therein. The USB flash drive can be used as an SFS. Therefore, the keys stored in the one-time programmable area are the keys of the secure SFS. The secure OS can access the GPIO corresponding to the one-key recovery confirmation button to determine whether the one-key recovery confirmation button is pressed. The one-key recovery confirmation button is a physical button on the U shield used to confirm one-key recovery.

[0137] Based on Figure 3 As shown in the system framework diagram, this optional example provides a solution for the secure one-key recovery system of BMC based on TrustZone secure file checksum and USB storage media. When manufacturing the U shield, the configuration file and authentication file encrypted by TrustZone can be stored in the USB storage device as the U shield. Since the encryption key is generated by the USB serial number, it ensures that each device has a unique key. And based on a series of security checks and state transition operations carried out by the secure OS in the secure monitoring mode, the key for configuration recovery and the key required for encrypting the configuration file (the aforementioned specified key) are both stored in the OTP area accessible by the secure OS, ensuring the security of the key and thus the security of the encrypted data. The above mechanism can achieve the secure one-key recovery function of the system in the scenario without accessing the network.

[0138] Figure 4It is a schematic diagram of an optional process for manufacturing a one-key recovery USB flash drive according to an embodiment of the present application. As Figure 4 shown, the process for manufacturing a one-key recovery USB flash drive may include the following steps S401 to S412. Among them, the BMC in the normal world refers to the aforementioned baseboard management controller operating system.

[0139] Step S401, after the BMC is configured, initialize the one-key recovery USB flash drive. The user's USB flash drive is connected to the server, and the user clicks to manufacture the one-key recovery USB flash drive on the BMC web human-computer interaction interface. In this case, the BMC initializes the one-key recovery USB flash drive.

[0140] Step S402, the BMC initiates an SMC call and sends a query request to the secure OS to query whether the server has ever manufactured a USB flash drive.

[0141] Step S403, the one-key recovery module of the secure OS queries whether there is data written to the OTP. If there is data written, it returns the query result that a one-key recovery USB flash drive has been manufactured. If it has not been manufactured, it returns the query result that a one-key recovery USB flash drive has not been manufactured, so that information such as the model and SN of the USB flash drive can be requested through the BMC. The information such as the model and SN of the requested USB flash drive is used to generate a secret key, and the generated secret key is written to the OTP to ensure that only one USB flash drive can be used for one machine.

[0142] Step S404, the secure OS returns the query result.

[0143] Step S405, the BMC sends the obtained information such as the model and SN of the USB flash drive to the secure OS, which can be sent through the secret key generation command.

[0144] Step S406, the one-key recovery module of the secure OS generates a hash value as the secret key of the secure SFS according to the model, SN and random number of the USB flash drive, and generates encrypted data as the unique secure secret key of the USB flash drive by using this secret key for the current model, SN and time of the USB flash drive.

[0145] Step S407, the secure OS returns the command execution result and the encrypted data.

[0146] Step S408, the BMC writes the obtained encrypted data into the USB flash drive and prompts the user that if this secret key is lost, the factory settings cannot be restored with one key.

[0147] Step S409, the BMC initiates a configuration encryption command and transfers the configuration file of the current server (including BMC-related configuration information) to the secure OS.

[0148] For the case where the configuration allows the U shield to be remade (allowing the configuration information saved in the U shield to be updated), if there is data written in the OTP, it indicates that the one - key recovery U shield has been made. The secure OS can request the security key of the USB flash drive (which can be the key derived in step S406) through the BMC, and can also request information such as the model and SN of the USB flash drive, and remake it after verifying that the U shield is legal. For the case of remaking the U shield, after verifying that the U shield is legal, steps S406 to S408 can be skipped and step S409 can be executed.

[0149] Step S410, the secure OS encrypts the configuration file transmitted by the BMC using the secure SFS key written to the OTP.

[0150] Step S411, the secure OS returns the command execution result and the encrypted configuration file.

[0151] Step S412, the BMC writes the encrypted configuration file returned by the secure OS to the USB flash drive and prompts the user that this data cannot be changed or deleted.

[0152] Figure 5 It is a schematic diagram of an optional one - key recovery process of the U shield according to an embodiment of the present application. As Figure 5 shown, the one - key recovery process may include the following steps S501 to S512, where the BMC in the normal world refers to the aforementioned baseboard management controller operating system.

[0153] Step S501, after the server accesses the one - key recovery U shield, the one - key recovery process of the BMC detects the access of the U shield and obtains the security key of the U shield from the U shield.

[0154] Step S502, the BMC initiates an SMC call, sends a one - key recovery system request to the secure OS, and transmits the security key of the USB flash drive to the secure OS.

[0155] Step S503, after the one - key recovery module of the secure OS detects the one - key recovery system request sent by the BMC, it verifies the security key of the USB flash drive using the key stored in the OTP.

[0156] Step S504, if the verification passes, the secure OS sends a one - key recovery confirmation request to the BMC. If the verification fails, the one - key recovery system request is ignored, or, a request result of rejecting the one - key recovery is returned.

[0157] Step S505, the BMC receives the one - key recovery confirmation request returned by the secure OS and prompts the user to press the one - key recovery confirmation button. The user can press the one - key recovery confirmation button on the U shield based on the prompt.

[0158] Step S506, the one-key recovery module of the secure OS detects that the one-key recovery confirmation button is pressed (through the GPIO that can only be accessed by the secure OS).

[0159] Step S507, the secure OS sends a command to the BMC to request the one-key recovery configuration file.

[0160] Step S508, the BMC receives the command sent by the secure OS to request the one-key recovery configuration file, and reads the encrypted configuration file stored in the USB key.

[0161] Step S509, the BMC transfers the encrypted configuration file to the secure OS.

[0162] Step S510, the secure OS decrypts the encrypted configuration file transferred by the BMC using the key of the secure SFS written to the OTP.

[0163] Step S511, the secure OS sends the decrypted configuration file back to the BMC.

[0164] Step S512, after receiving the decrypted configuration file sent back by the secure OS, the BMC performs configuration recovery on the BMC.

[0165] It should be noted that although the server architecture of a certain specific platform is used for description in this optional example, the provided configuration recovery method is not limited to the servers of this specific platform, and is also applicable to servers and computer platforms of other platforms.

[0166] Through this optional example, the configuration file and physical confirmation button of the one-key recovery function of the server BMC are placed in the secure TEE environment. The configuration file decryption and integrity verification are both encrypted using the internal key of the TEE, and are only decrypted after verification passes, and tampering is prevented by comparing hash values. In addition, the configuration recovery process is completed under the full monitoring of the TEE, blocking the intervention of the REE, ensuring the integrity of the system firmware and partition writing; moreover, the configuration of the BMC can be restored to a specified point in time without a network connection, improving the robustness of the server and providing guarantee for the stability of big data services.

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

[0168] According to another aspect of the embodiments of the present application, a baseboard management controller is further provided. The baseboard management controller can be used to implement the configuration recovery method of a baseboard management controller provided in any of the above embodiments, and those already described will not be repeated. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0169] Figure 6 is a structural block diagram of an optional baseboard management controller according to an embodiment of the present application. As Figure 6 shown in the figure, a first operating system 602 and a second operating system 604 are running on different hardware resources of the baseboard management controller, and the first operating system 602 runs in a trusted execution environment.

[0170] The first operating system 602 is configured to, when the server where the baseboard management controller is located accesses a first external device of a specified type, verify the first external device, and when the first external device passes the verification, send a recovery confirmation request to the first external device via the second operating system. The specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request to confirm the configuration recovery by pressing a specified button on the first external device; when it is detected that the specified button is pressed, obtain the first configuration information stored in the first external device via the second operating system, and use the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller.

[0171] The second operating system 604 is configured to send a recovery confirmation request to the first external device; perform configuration recovery on the baseboard management controller.

[0172] Through the embodiments provided in this application, a first operating system and a second operating system are running on different hardware resources of a baseboard management controller, and the first operating system runs in a trusted execution environment; when the server where the baseboard management controller is located accesses a first external device of a specified type, the first operating system verifies the first external device, and when the verification of the first external device is passed, a recovery confirmation request is sent to the first external device via the second operating system, where the specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request to confirm the configuration recovery by pressing a specified button on the first external device; when it is detected that the specified button is pressed, the first operating system obtains the first configuration information stored in the first external device via the second operating system, and uses the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller, solving the problem in the related art that the configuration recovery method of the baseboard management controller has poor security of the baseboard management controller due to the easy tampering of the configuration file, and improving the security of the baseboard management controller.

[0173] In some exemplary embodiments, the second operating system 604 is further configured to obtain first verification information stored in the first external device and pass the first verification information to the first operating system 602.

[0174] The first operating system 602 is further configured to receive the first verification information passed by the second operating system 604 and verify the first verification information using a specified secret key stored in the one-time programmable area, where the one-time programmable area only allows the first operating system to access.

[0175] In some exemplary embodiments, the specified secret key is generated according to the device identifier of the authorized device and a random number, and the authorized device is a device that allows configuration recovery of the baseboard management controller, and the device type of the authorized device is the specified type.

[0176] The first operating system 602 is further configured to query the one-time programmable area when the server accesses a second external device and configures the second external device as an authorized device, and when no data is written in the one-time programmable area, obtain the device identifier of the second external device via the second operating system 604, generate a specified secret key according to the device identifier of the second external device and a random number, and write the generated specified secret key into the one-time programmable area.

[0177] The second operating system 604 is further configured to obtain the device identifier of the second external device and pass the obtained device identifier of the second external device to the first operating system 602.

[0178] In some exemplary embodiments, the first operating system 602 is further configured to encrypt the device identifier and the current timestamp of the second external device using a specified secret key to obtain second verification information, and transmit the second verification information to the second operating system 604.

[0179] The second operating system 604 is further configured to write the second verification information as the device secret key of the second external device into the second external device for storage.

[0180] In some exemplary embodiments, the first operating system 602 is further configured to receive the second configuration information transmitted by the second operating system 604, encrypt the second configuration information using a specified secret key, and write the encrypted second configuration information into the second external device for storage via the second operating system 604, where the second configuration information is the configuration information of the baseboard management controller at a first moment.

[0181] The second operating system 604 is further configured to transmit the second configuration information to the first operating system 602; write the encrypted second configuration information into the second external device for storage.

[0182] In some exemplary embodiments, the first operating system 602 is further configured to obtain the device model of the second external device and the serial number of the second external device via the second operating system 604, where the device identifier of the second external device includes the device model of the second external device and the serial number of the second external device.

[0183] The second operating system 604 is further configured to obtain the device model of the second external device and the serial number of the second external device, and transmit the obtained device model of the second external device and the serial number of the second external device to the first operating system 602.

[0184] In some exemplary embodiments, the second operating system 604 is further configured to, when the server accesses the second external device, receive a configuration instruction sent by the first configuration device, where the configuration instruction is used to instruct to configure the second external device as an authorized device; send a query request to the first operating system 602, where the query request is used to request to query whether an authorized device has been configured for the baseboard management controller, and the one-time programmable region is executed after receiving the query request.

[0185] In some exemplary embodiments, the first configuration device includes a display screen, and the display screen is used to display an interaction interface of the baseboard management controller, where the interaction interface is an interface for configuring an authorized device for the baseboard management controller, and a configuration trigger control is displayed on the interaction interface.

[0186] The first configuration device is configured to, in response to a trigger operation performed on the configuration trigger control, send a configuration instruction to the baseboard management controller.

[0187] In some exemplary embodiments, the first operating system 602 is further configured to, when a specified key has been written in the one-time programmable area, obtain second verification information stored in a second external device via the second operating system 604, and verify the second verification information using the specified key; when the second verification information passes the verification, receive third configuration information transmitted by the second operating system 604, encrypt the third configuration information using the specified key, and write the encrypted third configuration information into the second external device via the second operating system 604 for storage, where the third configuration information is the configuration information of the baseboard management controller at a second moment.

[0188] The second operating system 604 is further configured to obtain second verification information stored in the second external device; write the encrypted third configuration information into the second external device for storage.

[0189] In some exemplary embodiments, the first operating system 602 is further configured to send a reconfiguration confirmation request to a second configuration device via the second operating system 604, where the second configuration device is a device that triggers the configuration of the second external device as the authorized device; when receiving a reconfiguration confirmation signal returned by the second configuration device in response to the reconfiguration confirmation request, send an information acquisition request to the second external device via the second operating system 604 to request to acquire verification information stored in the second external device.

[0190] The second operating system 604 is further configured to send a reconfiguration confirmation request to the second configuration device and is further configured to send an information acquisition request to the second external device.

[0191] In some exemplary embodiments, the specified key includes a first hash value obtained by hashing the device identifier of the authorized device, where the authorized device is a device that allows the configuration restoration of the baseboard management controller, and the device type of the authorized device is a specified type.

[0192] The first operating system 602 is further configured to decrypt the first verification information using the specified key to obtain the decrypted verification information, where the decrypted verification information includes a device identifier part; perform hashing on the device identifier part, and compare the obtained second hash value with the first hash value to verify the device identifier part.

[0193] In some exemplary embodiments, the decrypted verification information further includes a timestamp part.

[0194] The first operating system 602 is further configured to parse the timestamp part in a specified time format to verify the timestamp part.

[0195] In some exemplary embodiments, the first operating system 602 is further configured to decrypt the first configuration information using a specified key to obtain the decrypted configuration information, and send the decrypted configuration information back to the second operating system 604, so that the second operating system 604 can use the decrypted configuration information to perform configuration restoration on the baseboard management controller.

[0196] The second operating system 604 is further configured to perform configuration restoration on the baseboard management controller using the decrypted configuration information.

[0197] In some exemplary embodiments, the second operating system 604 is further configured to initiate a security monitoring mode call to the first operating system 602 and transmit first verification information to the first operating system 602.

[0198] In some exemplary embodiments, the first operating system 602 is further configured to access a specified port and determine whether a restoration confirmation signal is detected from the specified port, where the restoration confirmation signal is triggered by pressing a specified button, and the specified port is a port that only allows the first operating system 602 to access.

[0199] According to another aspect of the embodiments of the present application, a server is further provided. The server may include a baseboard management controller provided in any of the above embodiments, and details that have been described will not be repeated. Although the devices described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware is also possible and contemplated.

[0200] The server provided by the embodiments of the present application includes: a baseboard management controller, on which a first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment.

[0201] The first operating system is configured to, when the server is connected to a first external device of a specified type, verify the first external device, and when the verification of the first external device is passed, send a restoration confirmation request to the first external device via the second operating system, where the specified type is a device type for storing the configuration information of the baseboard management controller, and the restoration confirmation request is used to request confirmation of configuration restoration by pressing a specified button on the first external device; when it is detected that the specified button is pressed, obtain the first configuration information stored in the first external device via the second operating system, and use the first configuration information to control the second operating system to perform configuration restoration on the baseboard management controller.

[0202] The second operating system is configured to send a restoration confirmation request to the first external device; perform configuration restoration on the baseboard management controller.

[0203] The server is set to run a computer program to execute the steps in any of the above-described method embodiments for configuring and restoring a baseboard management controller.

[0204] It should be noted that the above-mentioned modules can be implemented by software or hardware. For the latter, it can be achieved in the following ways, but not limited to: all the above modules are located in the same processor; or, the above-mentioned modules are respectively located in different processors in any combination form.

[0205] According to another aspect of the embodiments of the present application, there is provided a computer-readable storage medium, where the computer-readable storage medium includes a stored program, and when the program runs, it executes the steps in any of the above method embodiments.

[0206] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various non-volatile storage media (non-transitory or non-transient storage media) such as USB flash drives, ROMs, RAMs, mobile hard disks, magnetic disks, or optical discs that can store computer programs.

[0207] According to another aspect of the embodiments of the present application, there is provided an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. The processor is set to execute the steps in any of the above method embodiments through the computer program. In an exemplary embodiment, the above electronic device may further include a transmission device and an input / output device, where the transmission device is connected to the above processor, and the input / output device is connected to the above processor.

[0208] Specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be elaborated here.

[0209] According to another aspect of the embodiments of the present application, there is also provided a computer program product, which includes a computer program / instructions, and the computer program / instructions include program codes for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit 701, it executes various functions provided by the embodiments of the present application. The above serial numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments.

[0210] Figure 7 Schematically shows a block diagram of a computer system of an electronic device for implementing the embodiments of the present application. As Figure 7As shown, computer system 700 includes a CPU (Central Processing Unit), i.e., central processor 701, which can perform various appropriate actions and processes according to a program stored in ROM 702 or a program loaded into RAM 703 from storage section 708. In random access memory 703, various programs and data required for system operation are also stored. Central processor 701, read-only memory 702, and random access memory 703 are connected to each other via bus 704. An I / O (Input / Output) interface 705 is also connected to bus 704.

[0211] The following components are connected to I / O interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including, for example, a CRT (Cathode Ray Tube), an LCD (Liquid Crystal Display), etc. and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a local area network card, a modem, etc. Communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to input / output interface 705 as required. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on drive 710 as required so that a computer program read therefrom can be installed into storage section 708 as required.

[0212] In particular, according to an embodiment of the present application, the processes described in each method flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for performing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processor 701, various functions defined in the system of the present application are executed.

[0213] It should be noted that Figure 7 the computer system 700 of the electronic device shown is only an example and should not impose any limitation on the functions and usage scope of the embodiments of the present application.

[0214] Obviously, those skilled in the art should understand that the various modules or steps of the present application described above can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program code executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a sequence different from that here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the present application is not limited to any specific combination of hardware and software.

[0215] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the principle of the present application shall be included within the protection scope of the present application.

Claims

1. A method for restoring the configuration of a baseboard management controller, characterized in that A first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment; the method includes: When a first external device of a specified type is connected to the server where the baseboard management controller is located, the first operating system verifies the first external device, and when the verification of the first external device is passed, a recovery confirmation request is sent to the first external device via the second operating system, where the specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request to confirm the configuration recovery by pressing a specified button on the first external device; When it is detected that the specified button is pressed, the first operating system obtains the first configuration information stored in the first external device via the second operating system, and uses the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller.

2. The method according to claim 1, wherein The verification of the first external device by the first operating system includes: The first operating system receives the first verification information stored in the first external device transmitted by the second operating system; the first operating system uses a specified secret key stored in the one-time programmable area to verify the first verification information, where the one-time programmable area only allows the first operating system to access.

3. The method according to claim 2, wherein The specified secret key is generated according to the device identifier of the authorized device and a random number, the authorized device is a device that allows configuration recovery of the baseboard management controller, and the device type of the authorized device is the specified type; Before the first operating system receives the first verification information stored in the first external device transmitted by the second operating system, the method further includes: When a second external device is connected to the server and the second external device is configured as the authorized device, the first operating system queries the one-time programmable area; When no data is written in the one-time programmable area, the first operating system obtains the device identifier of the second external device via the second operating system, generates the specified secret key according to the device identifier of the second external device and the random number, and writes the generated specified secret key into the one-time programmable area.

4. The method according to claim 3, characterized in that, After generating the specified secret key according to the device identifier of the second external device and the random number, the method further includes: The first operating system uses the specified secret key to encrypt the device identifier of the second external device and the current timestamp, obtains a second verification information, and writes the second verification information as the device secret key of the second external device into the second external device for storage via the second operating system.

5. The method according to claim 3, wherein After generating the specified secret key according to the device identifier of the second external device and the random number, the method further includes: Receive the second configuration information transmitted by the second operating system through the first operating system, encrypt the second configuration information using the specified secret key, and write the encrypted second configuration information to the second external device for storage through the second operating system, where the second configuration information is the configuration information of the baseboard management controller at the first moment.

6. The method according to claim 3, wherein The obtaining, by the first operating system via the second operating system, of the device identifier of the second external device includes: Obtain the device model of the second external device and the serial number of the second external device by the first operating system via the second operating system, where the device identifier of the second external device includes the device model of the second external device and the serial number of the second external device.

7. The method according to claim 3, characterized in that The method further includes: When the server accesses the second external device, receive a configuration instruction sent by a first configuration device through the second operating system, where the configuration instruction is used to instruct to configure the second external device as the authorized device; Send a query request from the second operating system to the first operating system, where the query request is used to request to query whether the authorized device has been configured for the baseboard management controller, and the query of the one-time programmable area is performed after receiving the query request.

8. The method according to claim 7, characterized in that Before the configuration instruction sent by the first configuration device is received through the second operating system, the method further includes: Display an interaction interface of the baseboard management controller on the display screen of the first configuration device, where the interaction interface is an interface for configuring the authorized device for the baseboard management controller, and a configuration trigger control is displayed on the interaction interface; In response to a trigger operation performed on the configuration trigger control, send the configuration instruction to the baseboard management controller.

9. The method according to claim 3, wherein After querying the one-time programmable area through the first operating system, the method further includes: When the specified secret key has been written in the one-time programmable area, obtain the second verification information stored in the second external device by the first operating system via the second operating system, and verify the second verification information using the specified secret key; When the second verification information is verified successfully, receive the third configuration information transmitted by the second operating system through the first operating system, encrypt the third configuration information using the specified secret key, and write the encrypted third configuration information to the second external device for storage through the second operating system, where the third configuration information is the configuration information of the baseboard management controller at the second moment.

10. The method according to claim 9, characterized in that, Before the second verification information stored in the second external device is obtained by the first operating system via the second operating system, the method further includes: Send a reconfiguration confirmation request from the first operating system via the second operating system to a second configuration device, where the second configuration device is the device that triggered the configuration of the second external device as the authorized device. In the case of receiving the reconfiguration confirmation signal returned by the second configuration device in response to the reconfiguration confirmation request, send an information acquisition request to the second external device via the second operating system through the first operating system, so as to request to acquire the verification information stored in the second external device.

11. The method according to claim 2, characterized in that, The specified secret key includes a first hash value obtained by hashing the device identifier of an authorized device, where the authorized device is a device that is allowed to perform configuration restoration on the baseboard management controller, and the device type of the authorized device is the specified type; The verification of the first verification information by using the specified secret key stored in the one-time programmable area through the first operating system includes: Decrypt the first verification information by using the specified secret key through the first operating system to obtain the decrypted verification information, where the decrypted verification information includes a device identifier part; Perform hashing on the device identifier part through the first operating system, and compare the obtained second hash value with the first hash value to verify the device identifier part.

12. The method according to claim 11, wherein The decrypted verification information further includes a timestamp part; The verification of the first verification information by using the specified secret key stored in the one-time programmable area through the first operating system further includes: Parse the timestamp part in a specified time format through the first operating system to verify the timestamp part.

13. The method according to claim 2, wherein The use of the first configuration information to control the second operating system to perform configuration restoration on the baseboard management controller includes: Decrypt the first configuration information by using the specified secret key to obtain the decrypted configuration information; Send the decrypted configuration information back to the second operating system, so that the second operating system uses the decrypted configuration information to perform configuration restoration on the baseboard management controller.

14. The method according to claim 2, wherein Before the verification of the first external device by the first operating system, the method further includes: Initiate a security monitoring mode call to the first operating system through the second operating system, and transmit the first verification information to the first operating system.

15. The method according to any one of claims 1 to 14, characterized in that, After the restoration confirmation request is sent to the first external device via the second operating system, the method further includes: Access a specified port through the first operating system, and determine whether a restoration confirmation signal is detected from the specified port, where the restoration confirmation signal is triggered by pressing the specified button, and the specified port is a port that only allows the first operating system to access.

16. A baseboard management controller, characterized in that, A first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment; where The first operating system is used to verify the first external device when the server where the baseboard management controller is located accesses a first external device of a specified type, and when the verification of the first external device is passed, send a recovery confirmation request to the first external device via the second operating system, where the specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request confirmation of configuration recovery by pressing a specified button on the first external device; when it is detected that the specified button is pressed, obtain the first configuration information stored in the first external device via the second operating system, and use the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller; The second operating system is used to send the recovery confirmation request to the first external device; perform configuration recovery on the baseboard management controller.

17. A server, characterized in that, Comprising: A baseboard management controller, where a first operating system and a second operating system are running on different hardware resources of the baseboard management controller, and the first operating system runs in a trusted execution environment; where The first operating system is used to verify the first external device when the server accesses a first external device of a specified type, and when the verification of the first external device is passed, send a recovery confirmation request to the first external device via the second operating system, where the specified type is a device type for storing the configuration information of the baseboard management controller, and the recovery confirmation request is used to request confirmation of configuration recovery by pressing a specified button on the first external device; when it is detected that the specified button is pressed, obtain the first configuration information stored in the first external device via the second operating system, and use the first configuration information to control the second operating system to perform configuration recovery on the baseboard management controller; The second operating system is used to send the recovery confirmation request to the first external device; perform configuration recovery on the baseboard management controller.

18. An electronic device, characterized in that, Comprising: A memory for storing computer programs; A processor for implementing the method according to any one of claims 1 to 15 when executing the computer program.

19. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, where the computer program, when executed by a processor, implements the method according to any one of claims 1 to 15.

20. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method according to any one of claims 1 to 15.

Images