A method and apparatus for loading server firmware

Abstract

The application discloses a server firmware loading method and device, and relates to the technical field of data processing. The method recovers the server firmware of an active area of a first nonvolatile memory by using a platform firmware recovery function when the server firmware check of the active area fails, and sends a switching instruction to the server to make the server switch to a second nonvolatile memory to load the server firmware, so that the switching timing of the server firmware loading source can be accurately controlled to ensure that the server service is not interrupted. After the recovery of the server firmware of the active area is completed, the version difference between the server firmware of the active area and the server firmware in the second nonvolatile memory is compared, and the loading source of the server firmware is selected according to a preset judgment strategy, so that the matching of the server area firmware version and the reasonable switching of the loading source are realized, and the running risk caused by the version mismatch is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to a server firmware loading method and device. BACKGROUND

[0002] In the technical field of servers, server firmware is the core basis for guaranteeing server startup, hardware initialization and system running, and the reliability of server firmware storage and loading directly determines the stability of the server. At present, server firmware is usually stored in a non-volatile memory, and the server firmware in the non-volatile memory is verified in the startup phase, and after the verification is passed, the server firmware is loaded to complete the startup process.

[0003] However, when the active area firmware verification of the non-volatile memory does not pass, the related art often has the problem that the server firmware recovery and the server firmware loading source switching do not connect well, which affects the reliable startup and normal operation of the server. SUMMARY

[0004] The present application provides a server firmware loading method and device to at least solve the problem that the server firmware recovery and the server firmware loading source switching do not connect well in the related art.

[0005] In a first aspect, the present application provides a server firmware loading method, comprising:

[0006] In the case that the server is in the startup phase, the server firmware of the active area of the first non-volatile memory is verified based on a platform firmware recovery function; wherein the active area is used to store the server firmware;

[0007] In response to the server firmware verification of the active area not passing, the server firmware of the active area is recovered based on the platform firmware recovery function, and a switching instruction is sent to the server; wherein the switching instruction is used to instruct the server to load the server firmware from the second non-volatile memory during the recovery of the server firmware of the active area;

[0008] In the case that the recovery of the server firmware of the active area is completed, the version number of the server firmware of the active area and the version number of the server firmware in the second non-volatile memory are obtained;

[0009] The version number of the server firmware of the active area and the version number of the server firmware in the second non-volatile memory are judged based on a preset judgment strategy, and the server loads the server firmware from the first non-volatile memory or the second non-volatile memory according to the judgment result.

[0010] In a second aspect, the present application further provides a server firmware loading device, comprising:

[0011] The checking module is configured to check the server firmware of the active area of the first non-volatile memory based on the platform firmware recovery function when the server is in a booting stage, wherein the active area is configured to store the server firmware.

[0012] The firmware recovery and instruction sending module is configured to, in response to the server firmware of the active area failing the check, recover the server firmware of the active area based on the platform firmware recovery function, and send a switching instruction to the server, wherein the switching instruction is configured to instruct the server to load the server firmware from the second non-volatile memory during the recovery of the server firmware of the active area.

[0013] The obtaining module is configured to, when the recovery of the server firmware of the active area is completed, obtain a version number of the server firmware of the active area and a version number of the server firmware in the second non-volatile memory.

[0014] The switching judging module is configured to judge the version number of the server firmware of the active area and the version number of the server firmware in the second non-volatile memory based on a preset judging strategy, and cause the server to load the server firmware from the first non-volatile memory or the second non-volatile memory according to a judging result.

[0015] In a third aspect, the present application further provides an electronic device, comprising:

[0016] A memory configured to store a computer program.

[0017] A processor configured to implement the steps of the server firmware loading method of the first aspect when executing the computer program.

[0018] In a fourth aspect, the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the server firmware loading method of the first aspect.

[0019] In a fifth aspect, the present application further provides a computer program product comprising a computer program, and the computer program is executed by a processor to implement the steps of the server firmware loading method of the first aspect.

[0020] The application provides a server firmware loading method and device. When the server firmware in the active area of the first nonvolatile memory fails to pass the verification, the platform firmware recovery function is used to recover the server firmware in the active area, and a switching instruction is sent to the server to switch to the second nonvolatile memory to load the server firmware. Therefore, the switching timing of the server firmware loading source is accurately controlled to ensure that the server service is not interrupted, and the service loss caused by the failure of the server firmware is effectively avoided. After the recovery of the server firmware in the active area is completed, the version difference between the server firmware in the active area and the server firmware in the second nonvolatile memory is compared, and the loading source of the server firmware is selected according to a preset judgment strategy, so that the matching of the server firmware version and the reasonable switching of the loading source are realized, and the server firmware after the switching has better functionality, security or compatibility, and the running risk caused by the version mismatch is reduced. Therefore, the method of the application can effectively solve the problems of low starting efficiency or unstable running caused by the poor connection of the switching mechanism and the version mismatch, and guarantee the reliable starting and stable running of the server. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0022] Figure 1 An application scenario diagram corresponding to a server firmware loading method provided by an embodiment of the application is shown in the figure.

[0023] Figure 2 A flowchart of a server firmware loading method provided by an embodiment of the application is shown in the figure.

[0024] Figure 3 A flowchart of a server firmware loading method provided by another embodiment of the application is shown in the figure.

[0025] Figure 4 A flowchart of a server firmware loading method provided by another embodiment of the application is shown in the figure.

[0026] Figure 5 A structural diagram of a server firmware loading device provided by an embodiment of the application is shown in the figure.

[0027] Figure 6 A structural diagram of an electronic device provided by an embodiment of the application is shown in the figure. DETAILED DESCRIPTION

[0028] With reference to the drawings and specific embodiments described below, the technical solutions in the embodiments of the present application will be clearly and completely described, obviously, the described embodiments are only a part of the embodiments of the present application, not 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 labor fall within the scope of protection of the present application.

[0029] In order for those skilled in the art in the technical field to better understand the solutions of the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0030] In the field of server technology, server firmware is the core basis for ensuring server startup, hardware initialization and system operation. Server firmware is the core program for server startup and hardware initialization. Server firmware can be basic input / output system, unified extensible firmware interface, etc. The reliability of server firmware storage and loading directly determines the stability of the server.

[0031] Currently, server firmware is usually stored in a non-volatile memory. In the boot stage, the PFR function (Platform Firmware Resilience) is used to verify the server firmware in the active area of the non-volatile memory. After the verification is passed, the server firmware is directly loaded from the active area to complete the boot process. If the verification of the server firmware in the active area fails, the PFR function writes the mirror file of the server firmware in the recovery area of the non-volatile memory to the active area, and then restarts the server. However, there is a problem in the related art that the server firmware recovery and loading source switching mechanism do not work well together. For example, the loading source switching timing of the server firmware is not reasonable, it is difficult to effectively select according to the server firmware version after switching, which easily leads to server startup interruption, low loading efficiency or unstable operation due to server firmware version mismatch, etc., affecting the reliable startup and normal operation of the server.

[0032] Therefore, in the face of the above technical problems of the related art, in order to solve the problem that the server firmware recovery and loading source switching mechanism do not work well together. When the verification finds that the firmware in the active area of the non-volatile memory is abnormal, the recovery is started with the help of the platform firmware recovery function, and at the same time, the server is instructed to load the server firmware from other non-volatile memories during recovery by sending a switching instruction, so as to accurately control the switching timing to ensure that the server does not interrupt the service; after the recovery of the server firmware in the active area is completed, the version numbers of the server firmware in the two non-volatile memories are compared, and the loading source is selected according to the preset judgment strategy, realizing the matching of the service area firmware version and the reasonable switching of the loading source, effectively solving the problems of low startup efficiency or unstable operation caused by the mismatch of the switching mechanism and the version, and ensuring the reliable startup and stable operation of the server.

[0033] Figure 1 A server firmware loading method provided by an embodiment of the present application corresponds to an application scenario. As shown in Figure 1 the application scenario includes a first nonvolatile memory 10 and a loading device 11, and the first nonvolatile memory 10 and the loading device 11 are communicatively connected. Specifically, in a case where a server is in a booting stage, the loading device 11 verifies server firmware of an active area of the first nonvolatile memory 10 based on a platform firmware recovery function; the active area is used to store the server firmware; in a case where the server firmware of the active area fails to pass verification, the loading device 11 recovers the server firmware of the active area based on the platform firmware recovery function, and sends a switching instruction to the server; the switching instruction is used to instruct the server to load the server firmware from a second nonvolatile memory during recovery of the server firmware of the active area; in a case where the recovery of the server firmware of the active area is completed, a version number of the server firmware of the active area and a version number of the server firmware in the second nonvolatile memory are obtained; the loading device 11 judges the version number of the server firmware of the active area and the version number of the server firmware in the second nonvolatile memory based on a preset judgment strategy, and causes the server to load the server firmware from the first nonvolatile memory 10 or the second nonvolatile memory according to a judgment result.

[0034] The technical solutions of the present application and how the technical solutions of the present application solve the above technical problems will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described again in some embodiments. The embodiments of the present application will be described below with reference to the drawings.

[0035] Figure 2 A flowchart of a server firmware loading method provided by an embodiment of the present application is shown in Figure 2 The execution subject of the embodiment is a server firmware loading device. The server firmware loading can be realized by a computer program, or by a medium storing the related computer program, such as a U disk and / or an optical disk, etc. Alternatively, the server firmware loading can also be realized by an entity device integrated or installed with the related computer program, such as a chip, an electronic device, etc. The electronic device can be a computer or a server, etc. The server firmware loading method provided by the embodiment includes the following steps.

[0036] S201, in a case where a server is in a booting stage, verifying server firmware of an active area of a first nonvolatile memory based on a platform firmware recovery function; the active area is used to store the server firmware.

[0037] Specifically, in the case that the server is in a power-on stage, i.e., after the server is powered on, a process stage of hardware initialization and firmware starting is started, a platform firmware recovery function built-in the server is started, and the server firmware stored in the active area of the first non-volatile memory is verified.

[0038] The first non-volatile memory is a main firmware storage medium of the server, and can be a serial peripheral interface flash memory, which has the characteristics of fast read-write speed, high stability, and adaptation to the hardware architecture of the server. The active area is a specific area in the first non-volatile memory, which is pre-divided and used to store the effective server firmware to be loaded currently. The active area is independent of the recovery area in the first non-volatile memory, and the server firmware in the recovery area can be used as a recovery source when the server firmware in the active area is damaged.

[0039] The platform firmware recovery function is a preset function integrated in the hardware management module of the server, such as a baseboard management controller (BMC), and has the capabilities of firmware integrity verification, firmware data recovery, and instruction sending, and can be started autonomously at the initial stage of server booting without relying on external control.

[0040] It should be noted that the core purpose of the server firmware verification is to determine whether the server firmware in the active area has normal loading conditions. The verification method can use integrity verification algorithms such as cyclic redundancy check and message digest algorithm. The verification value of the current server firmware in the active area is compared with a preset standard verification value, which is pre-stored in the first non-volatile memory and is the verification value of the normal version of the server firmware. If the two are consistent, it is determined that the verification is passed, and the server loads the server firmware from the active area normally. If the two are inconsistent, it is determined that the verification is not passed, indicating that the server firmware in the active area is damaged, tampered with, or data is lost, and the subsequent recovery step needs to be performed.

[0041] S202, in response to the server firmware in the active area not passing the verification, the server firmware in the active area is recovered based on the platform firmware recovery function, and a switching instruction is sent to the server; wherein the switching instruction is used to instruct the server to load the server firmware from the second non-volatile memory during the recovery of the server firmware in the active area.

[0042] The specific implementation of the firmware recovery process is that the platform firmware recovery function first sends a data reading instruction to the recovery area of the first non-volatile memory to call the complete and valid image file of the server firmware stored in the recovery area; then, the platform firmware recovery function performs a data overwrite operation on the active area to completely write the image file of the recovery area into the active area to overwrite the original damaged server firmware file; during the writing process, the platform firmware recovery function monitors the writing progress and data integrity in real time, and if a writing error occurs, the reading and writing operations are re-executed until the recovery is completed.

[0043] The switching instruction is a control signal with explicit execution logic, and the function of the switching instruction is to instruct the server to switch the loading source of the server firmware during the server firmware recovery in the active area, that is, to switch from the original active area of the first non-volatile memory to the second non-volatile memory.

[0044] The second non-volatile memory is a backup server firmware storage medium of the server, and the type of the second non-volatile memory can be the same as or different from that of the first non-volatile memory, for example, it can also be a solid state disk, a mechanical hard disk, or an embedded multimedia card. The second non-volatile memory pre-stores the server firmware consistent with or compatible with the firmware version of the active area of the first non-volatile memory, and the storage location and data format thereof have been pre-registered in the loading control module of the server to ensure that the loading control module can quickly identify and read the server firmware in the second non-volatile memory.

[0045] It should be noted that since the server firmware recovery in the active area of the first non-volatile memory requires a certain time, if the server waits for the recovery to be completed before loading the server firmware, it will cause the boot to be stalled; and by switching to the second non-volatile memory to load the server firmware, the server can normally complete the boot and business operation during the recovery period, achieving the effect of uninterrupted operation during recovery.

[0046] For example, if the server is a cloud computing node server, after loading the server firmware from the second non-volatile memory during the recovery period, the server can normally receive and process the computing tasks issued by the cloud platform, avoiding business interruption.

[0047] S203, in the case where the server firmware recovery in the active area is completed, the version number of the server firmware in the active area and the version number of the server firmware in the second non-volatile memory are obtained.

[0048] Optionally, the platform firmware recovery function can synchronously obtain the version numbers of the firmware in the two storage media in two ways: one is to read the version identification information of the server firmware itself. The server firmware will write the version number into the header fixed field of the server firmware image when compiling. The platform firmware recovery function can directly extract the field information from the active area of the first non-volatile storage and the firmware storage partition of the second non-volatile storage by sending a version reading instruction. The second is to call the pre-stored version record. The BMC or hardware management module of the server pre-stores a firmware version mapping table. The firmware version mapping table records the firmware version numbers currently stored in the active area of the first non-volatile storage and the second non-volatile storage. The platform firmware recovery function can quickly obtain the version information by accessing the firmware version mapping table.

[0049] Optionally, the version number is in the format of a combination of "major version number - minor version number - patch version number", for example, V2.6.3, wherein "2" is the major version number, representing the iteration of the core function; "6" is the minor version number, representing the added function; and "3" is the patch version number, representing the bug fixing, ensuring that the subsequent comparison logic can be quantitatively executed.

[0050] S204, judging the version number of the server firmware in the active area and the version number of the server firmware in the second non-volatile storage based on a preset judgment strategy, and causing the server to load the server firmware from the first non-volatile storage or the second non-volatile storage according to the judgment result.

[0051] It should be noted that by comparing the version difference between the server firmware in the active area and the firmware in the second non-volatile storage, it is ensured that the server firmware after switching has better functionality, security or compatibility, and reduces the running risk caused by version mismatch.

[0052] The preset judgment strategy is a strategy of judgment logic preset based on the actual running demand of the server. The purpose of the preset judgment strategy is to ensure that the switching operation will not affect the current stability and business continuity of the server.

[0053] Optionally, the platform firmware recovery function can select the version number judgment logic from at least one of the following rules according to the preset application scenario of the server:

[0054] Firstly, the major version numbers can be compared according to the high version priority rule. If the major version number of the active area > the major version number of the second non-volatile storage, the loading source of the server firmware can be switched to the active area of the first non-volatile storage. If the major version numbers are the same, the minor version numbers can be compared. The one with higher minor version number has priority. If the major and minor version numbers are the same, the patch version numbers are compared. The one with higher patch version number has priority.

[0055] Secondly, a version security vulnerability association library can be established in advance according to a security patch priority rule, the version security vulnerability association library stores known vulnerability information of each version, and if the second nonvolatile memory version exists an unpatched high-risk vulnerability and the server firmware of the active area is recovered, the server is switched to load the server firmware from the active area of the first nonvolatile memory regardless of the version number.

[0056] It should be noted that the version number of the server firmware of the active area is determined by the preset determination strategy, and the server loads the server firmware from the first nonvolatile memory or the second nonvolatile memory according to the determination result, so that the server can be prevented from switching back to the old version firmware with high-risk vulnerabilities or missing the new version firmware.

[0057] The server firmware loading method provided by the embodiment of the application can restore the server firmware of the active area by using the platform firmware recovery function when the server firmware of the active area of the first nonvolatile memory fails the verification, and send a switching instruction to the server to switch to load the server firmware from the second nonvolatile memory, so that the switching timing of the server firmware loading source can be accurately controlled to ensure that the server business is not interrupted, and the business loss caused by the failure of the server firmware is effectively avoided. After the server firmware of the active area is restored, the version difference between the server firmware of the active area and the firmware in the second nonvolatile memory is compared, and the loading source is selected according to the preset determination strategy, so that the matching of the service area firmware version and the reasonable switching of the loading source are realized, and the server firmware after switching has better functionality, security or compatibility, and the running risk caused by version mismatch is reduced. Therefore, the method of the application can effectively solve the problems of low starting efficiency or unstable running caused by poor connection of the switching mechanism and version mismatch, and ensure the reliable starting and stable running of the server.

[0058] Figure 3 A flowchart of a server firmware loading method provided by another embodiment of the application is shown in FIG. 6. Figure 3 As an optional implementation, according to the determination result, the server loads the server firmware from the first nonvolatile memory or the second nonvolatile memory, which includes the following steps:

[0059] S301, if the version number of the server firmware in the second nonvolatile memory is higher than the version number of the server firmware of the active area of the first nonvolatile memory, the server keeps loading the server firmware from the second nonvolatile memory.

[0060] S302, in the case that the version number of the server firmware in the first non-volatile memory is higher than the version number of the server firmware in the active area of the second non-volatile memory, sending a switching instruction to the server, and the server switches to load the server firmware from the active area of the first non-volatile memory.

[0061] Optionally, the version numbers of the firmware in the first non-volatile memory and the second non-volatile memory are acquired, and the major version number, the minor version number and the patch version number are sequentially judged. For example, if the major version number of version A is greater than the major version number of version B, it is directly determined that version A is higher; if the major version numbers are the same, the version with the higher minor version number is better; if the major version number and the minor version number are the same, the version with the higher patch version number is better. If the three-level version numbers are completely the same, it is determined that there is no difference between the versions.

[0062] Optionally, when it is determined that the version number of the server firmware in the second non-volatile memory is higher than the version number of the server firmware in the active area of the first non-volatile memory, a loading source locking instruction is sent to the firmware loading control module (such as a central processing unit or a loading controller) of the server, to explicitly instruct to keep loading the firmware from the second non-volatile memory.

[0063] Optionally, if an operation and maintenance personnel needs to forcibly switch to load the server firmware from the active area of the first non-volatile memory, a "forced switching instruction" can be sent through a server management interface. After receiving the instruction, the loading control module of the server firmware skips the version judgment and executes the switching operation.

[0064] Optionally, when it is determined that the version number of the server firmware in the active area of the first non-volatile memory is higher than the version number of the server firmware in the second non-volatile memory, a switching instruction is sent to the loading control module of the server, and the server switches to load the server firmware from the active area of the first non-volatile memory.

[0065] The loading method of the server firmware provided in the embodiments of the present application keeps the loading source when the version of the second non-volatile memory is higher, and makes the server switch to load the server firmware from the active area of the first non-volatile memory when the version of the first non-volatile memory is higher. Therefore, the server can load the server firmware with a higher version.

[0066] Figure 4 A flowchart of a loading method of a server firmware according to another embodiment of the present application is shown in FIG. 5. Figure 4 As an optional implementation, according to the judgment result, the server loads the server firmware from the first non-volatile memory or the second non-volatile memory, which includes the following steps:

[0067] S401, acquire a historical version number of server firmware loaded last time in normal runtime on the server.

[0068] S402, determine a first difference degree of the version number of server firmware in the active area of the first non-volatile memory and the historical version number, and a second difference degree of the version number of server firmware in the second non-volatile memory and the historical version number.

[0069] S403, in the case that the first difference degree is less than or equal to the second difference degree, send a switching instruction to the server, and the server switches to load the server firmware from the active area of the first non-volatile memory.

[0070] S404, in the case that the first difference degree is greater than the second difference degree, the server keeps loading the server firmware from the second non-volatile memory.

[0071] It should be noted that by calculating the difference degree of the current firmware version and the historical version, the loading source closer to the historical stable version is selected, so as to avoid the hardware compatibility risk or function adaptation problem caused by too large version span.

[0072] Optionally, after the server completes normal booting and the server firmware is stable after being loaded each time, the version number of the last normal running firmware, the running date and time, and the corresponding loading source identifier are stored to a non-volatile special partition of the basic management controller, the non-volatile special partition has power-off saving capability and only allows additional writing and reading operations, so as to avoid version data tampering.

[0073] Optionally, the version number is disassembled into three levels according to "major version number, minor version number, and patch version number", and each level corresponds to different weights. For example, the major version number weight is 5, the minor version number weight is 3, and the patch version number weight is 1. If the historical version number is V2.5.3 (major version number 2, minor version number 5, and patch version number 3), the active area version V2.6.3, the major version number is equal (difference 0), the minor version number is different by 1 (difference: 1*3=3), and the patch version number is equal (difference 0), the first difference degree is 3; the second non-volatile memory version V3.5.3, the major version number is different by 1 (1*5=5), the minor and patch versions are equal (difference 0), and the second difference degree is 5.

[0074] Optionally, when it is determined that the first difference degree of the active area version and the historical version is less than or equal to the second difference degree of the second non-volatile memory version and the historical version, it indicates that the version of the server firmware in the active area is closer to the historical version of the last stable running, and the compatibility risk is lower, and the server is switched to load the server firmware from the active area of the first non-volatile memory.

[0075] Optionally, when it is determined that the first difference degree is greater than the second difference degree, it indicates that the version of the server firmware in the second non-volatile memory is closer to the historical version, and the operation of keeping the current loading source is performed.

[0076] The loading method of the server firmware provided in the embodiments of the present application avoids the problems of hardware driver incompatibility, function loss and the like caused by large version span by selecting a loading source close to the historical version.

[0077] As an optional implementation, on the basis of any one of the embodiments described above, the server firmware in the active area of the first non-volatile memory is verified based on a platform firmware recovery function, comprising:

[0078] Firstly, the key, the region data and the signature data of the active area are obtained.

[0079] Optionally, the platform firmware recovery function first obtains three types of data required for verification: the key, the region data of the active area and the signature data, to ensure that the data source is safe and corresponds to only one.

[0080] Optionally, the key can be a public key in an asymmetric encryption system, wherein the public key is pre-installed on the server and used for verification, and a private key is kept by the server firmware developer and used for generating the signature data. Optionally, the public key can be stored in an encryption special partition of the server hardware security module or the BMC, and the public key is called through a hardware security interface, and encrypted transmission is adopted in the calling process to prevent the public key from being intercepted and tampered with.

[0081] Optionally, the complete firmware data of the active area of the first non-volatile memory is read, including the firmware image header, the code segment, the data segment and all regions, to obtain the region data of the active area.

[0082] Optionally, the signature data is generated by the firmware developer when the server firmware is released, is encrypted by the private key on the hash value of the region data, and is stored in the signature special sub-partition of the active area together with the server firmware.

[0083] Secondly, a first hash value corresponding to the active area is determined according to the key and the region data, and a second hash value corresponding to the active area is determined according to the region data and the signature data.

[0084] Optionally, the platform firmware recovery function adopts a preset hash algorithm to calculate the first hash value and the second hash value.

[0085] Optionally, a hash operation is performed on the obtained region data of the active area to obtain an original hash value, and if an asymmetric encryption system is adopted, the obtained public key is used for verification operation on the original hash value, the verification operation is to confirm whether the original hash value is generated by the signature corresponding to the private key, and after the verification operation is passed, the original hash value is taken as the first hash value.

[0086] Optionally, the encrypted hash segment in the signature data is extracted, and if an asymmetric encryption system is used, a decryption operation is performed on the encrypted hash segment using a public key to obtain a decrypted hash value, and the decrypted hash value is taken as the second hash value. The decrypted hash value should be the hash value calculated by the developer for the region data at the time of firmware release.

[0087] Then, the first hash value and the second hash value are compared. If the first hash value and the second hash value are the same, it is determined that the server firmware of the active region of the first non-volatile memory passes the verification; if the first hash value and the second hash value are not the same, it is determined that the server firmware of the active region of the first non-volatile memory fails the verification.

[0088] Specifically, the platform firmware recovery function performs a byte-level comparison between the calculated first hash value and the second hash value, and determines whether the verification passes according to the comparison result. If each byte of the first hash value and the second hash value is the same, it indicates that the region data of the active region has not been tampered with, and at this time the platform firmware recovery function marks that the server firmware of the active region passes the verification, and the server loads the server firmware from the active region. If there is any byte difference between the first hash value and the second hash value, it indicates that the server firmware of the active region may be tampered with, the data may be damaged, or the firmware may come from an illegal source, and at this time the platform firmware recovery function marks that the active region firmware fails the verification.

[0089] Optionally, to avoid misjudgment caused by temporary hardware fluctuations, the platform firmware recovery function can perform 1 to 2 retry verifications, and if the verification still fails after retrying, it is determined that the verification fails.

[0090] The server firmware loading method provided by the embodiment of the application can effectively resist attacks of re-computing the check value after tampering with the data by combining digital signature and public key verification, and can confirm whether the server firmware is an authorized version of the developer by public key verification, thereby avoiding loading unauthorized server firmware.

[0091] As an optional implementation, based on any one of the above embodiments, the platform firmware recovery function verifies the server firmware of the active region of the first non-volatile memory, including the following steps:

[0092] First, the server firmware of the active region is divided into a plurality of data blocks, and a plurality of threads are used to perform verification calculation on the plurality of data blocks respectively.

[0093] Optionally, the server firmware of the active area of the first non-volatile memory is first structured into blocks, ensuring that the block data is independent and easy to process in multiple threads. Optionally, the block size of the data blocks needs to be aligned with the physical block size of the first non-volatile memory, avoiding performance loss caused by cross-physical block reading. For example, the SPI Flash (Serial Peripheral Interface Flash) is usually 4KB / 8KB / 64KB.

[0094] Illustratively, if the size of the server firmware of the active area is 16MB, the SPI Flash physical block size is 64KB, and the CPU is 8-core, the block size is set to 64KB, the total number of blocks = 16MB / 64KB = 256 blocks, and the number of threads is set to 8, with each thread processing 32 blocks.

[0095] Optionally, if the total size of the server firmware cannot be divided by the block size, the last block is divided according to the actual remaining size and marked as a tail block to avoid data truncation.

[0096] Optionally, a unique block index is assigned to each block of data, and a block length, a check algorithm identifier, and an integrity identifier bit are added to the block header. In addition, a block index table is established to record the starting address and expected check value of each block, facilitating subsequent thread positioning and result comparison.

[0097] Optionally, the platform firmware recovery function implements multi-thread parallel verification through a thread pool management module to avoid the overhead of thread creation and destruction and resource competition, wherein the thread pool management module can be integrated into the CPU scheduling unit.

[0098] Optionally, according to the assigned unique block index, the corresponding data block is read from the active area, and it is verified whether the block length in the header of the data block is consistent with the actual read length. If not, it is marked as a block damage. Then, a hash algorithm consistent with the block identifier is used to calculate the check value of the data block, and the expected check value of the current data block is retrieved from the block index table, and the actual check value and the expected check value are compared. If the actual check value and the expected check value are consistent, the integrity identifier bit in the header of the data block is set to 1, indicating that the verification is passed. If the actual check value and the expected check value are not consistent, the block verification fails. After completing the verification of all allocated data blocks, the thread sends a task completion signal to the thread pool management module and enters an idle state.

[0099] Secondly, after each thread completes the verification calculation, the verification results of each data block are obtained. In the case that the verification of each data block is passed, it is determined that the server firmware of the active area of the first non-volatile memory is verified to pass.

[0100] Optionally, when all threads send the task completion signal, the platform firmware recovery function performs result aggregation to determine the overall verification result of the active area server firmware. By reading the verification result of all data blocks, when the integrity identification bit of all data blocks is 1, it is determined that the active area server firmware of the first non-volatile memory passes the verification.

[0101] The server firmware loading method provided by the embodiments of the present application can shorten the verification time and avoid server boot delay caused by too long verification time by performing verification on the active area server firmware in parallel through multiple threads.

[0102] As an optional implementation, on the basis of any one of the above embodiments, the first non-volatile memory further includes a recovery area, and the recovery area is used to store a mirror file of the server firmware.

[0103] The recovery area is an independent partition of the first non-volatile memory and does not overlap with the address of the active area.

[0104] Specifically, in response to the verification of the active area server firmware failing, the active area server firmware is recovered based on the platform firmware recovery function, including the following steps:

[0105] In response to the verification of the active area server firmware failing, the mirror file of the recovery area of the first non-volatile memory is verified; and in the case that the mirror file of the recovery area passes the verification, the active area server firmware is recovered based on the platform firmware recovery function using the mirror file of the recovery area.

[0106] It should be noted that, in order to avoid recovery failure caused by using a damaged mirror file of the recovery area, the integrity and legality of the mirror file stored in the recovery area can be verified first. Optionally, the platform firmware recovery function reads the complete mirror file of the recovery area through the memory bus, and the data can be verified through the above-mentioned hash value verification method.

[0107] Optionally, in the case that the mirror file of the recovery area passes the verification, the active area server firmware is recovered using the mirror file; and in the case that the mirror file of the recovery area fails the verification, an alarm of mirror damage of the recovery area can be sent to the basic management controller, and the server firmware of the active area of the first non-volatile memory can be temporarily recovered using the firmware of the second non-volatile memory.

[0108] Optionally, after the mirror file of the recovery area passes the verification, the platform firmware recovery function performs overwrite recovery on the active area server firmware using the mirror file. Optionally, during the recovery, the current partition table of the active area is read, the partition table records the address range of each sub-partition of the active area, and it is ensured that only the data area of the server firmware is overwritten during the recovery, without damaging the partition structure.

[0109] It should be noted that the mirror file of the recovery area is checked at the beginning of the switching instruction sent to the loading control module, indicating that the server loads the server firmware from the second non-volatile memory.

[0110] The server firmware loading method provided by the embodiment of the application avoids the use of damaged mirror files to cause recovery failure by checking the mirror file of the recovery area.

[0111] As an optional implementation, on the basis of any one of the above embodiments, the first non-volatile memory further includes a recovery area, and the recovery area is used to store the mirror file of the server firmware.

[0112] Specifically, in response to the server firmware of the active area failing to pass the check, the mirror file of the recovery area of the first non-volatile memory is checked, including the following steps:

[0113] In the case that the mirror file of the recovery area fails to pass the check, the backup mirror of the server firmware in the second non-volatile memory is acquired; the backup mirror is subjected to hash value check and signature verification, and in the case that the backup mirror passes the check, the backup mirror is written into the recovery area of the first non-volatile memory, and the server firmware of the active area is recovered based on the backup mirror of the recovery area.

[0114] Optionally, when it is determined that the recovery area mirror check fails, the platform firmware recovery function starts recovery area repair, first, the backup mirror of the server firmware is acquired from the second non-volatile memory.

[0115] Optionally, the firmware backup security partition is pre-divided in the second non-volatile memory, and the firmware backup security partition only allows the platform firmware recovery function to access.

[0116] The backup mirror is stored in a standard mirror format, the file name contains a version identifier, the mirror header stores the creation time, the adapted server model and the hash algorithm identifier, and the matching with the current server is ensured.

[0117] Optionally, to ensure that the acquired backup mirror is not tampered with and is legal, hash value check and signature verification double check need to be performed, and the check order can be flexibly adjusted. Further, the hash value check can be performed first to quickly exclude obviously damaged mirrors.

[0118] Optionally, the hash algorithm identifier of the backup image header is extracted, and a hash value of the backup image is actually calculated by using a hash algorithm corresponding to the hash algorithm identifier. The expected hash value is read from the check value storage sub-partition of the second non-volatile memory; the actually calculated hash value is compared with the expected hash value, if the actually calculated hash value is consistent with the expected hash value, the signature verification link is entered; if the actually calculated hash value is inconsistent with the expected hash value, it is determined that the image data is damaged, and the recovery area repair is terminated.

[0119] Optionally, the digital signature segment of the backup image tail is read, the public key is called from the security storage area of the BMC of the server, the digital signature segment is decrypted by using the public key, and the decrypted original hash value of the image is obtained; the decrypted original hash value is compared with the actually calculated hash value of the backup image calculated above, if the original hash value is consistent with the actually calculated hash value, it is determined that the signature verification is passed, and the backup image is legal; if the original hash value is inconsistent with the actually calculated hash value, it is determined that the backup image is tampered, and the subsequent write operation is prohibited.

[0120] Optionally, the platform firmware recovery function writes the backup image into the recovery area of the first non-volatile memory, and completes the recovery area repair.

[0121] Optionally, when the double check of the backup image is passed, the partition cleaning operation is performed on the recovery area of the first non-volatile memory, and the original damaged image file is deleted. Then, the backup image is split according to the physical block size of the recovery area, and is sequentially written into the recovery area. Optionally, the repair progress of the recovery area is output in real time by the BMC in the writing process.

[0122] Optionally, when the backup image is completely written, the whole recovery area is checked once, if the check is passed, the recovery area repair success notification is sent to the BMC; if the check fails, it is determined that the recovery area repair is abnormal.

[0123] Optionally, if the hash value check fails or the signature verification is not passed, the platform firmware recovery function immediately terminates the recovery area repair, and sends the backup image unusable alarm to the BMC.

[0124] The server firmware loading method provided by the embodiment of the application can not only make the server temporarily load the backup image in the second non-volatile memory to ensure the normal operation of the business, but also use the backup image as the repair source of the recovery area when the image file of the recovery area fails to pass the check.

[0125] As an optional implementation, on the basis of any one of the above embodiments, the first non-volatile memory further includes a recovery area and a buffer area, the recovery area is used for storing the image file of the server firmware, and the buffer area is used for storing the temporary file of the server firmware upgrade.

[0126] Optionally, the complete firmware upgrade package is included in the temporary file, and the firmware upgrade package includes an upgrade script, an image file and verification information. When the upgrade is successful, the buffer temporary file is automatically deleted; when the upgrade is interrupted / fails, the temporary file is retained.

[0127] Specifically, in response to the server firmware of the active area failing to pass the verification, the server firmware of the active area is recovered based on the platform firmware recovery function, including the following steps:

[0128] First, in response to the server firmware of the active area failing to pass the verification, the temporary file of the server firmware upgrade of the buffer of the first non-volatile memory is verified.

[0129] Second, in the case that the temporary file of the buffer passes the verification, the temporary file of the buffer is used to recover the server firmware of the active area based on the platform firmware recovery function. In the case that the temporary file of the buffer fails to pass the verification, the image file of the recovery area is used to recover the active area based on the platform firmware recovery function.

[0130] It should be noted that in the existing server firmware upgrade process, the server firmware of the active area needs to be recovered by relying on the recovery area after being damaged, and the recovery area image may be an old version, resulting in the loss of upgrade achievements. Therefore, the upgrade temporary file stored in the independent buffer can be used for recovery, taking into account the recovery efficiency and version timeliness.

[0131] Optionally, the platform firmware recovery function is used to first detect whether there is an undelleted complete upgrade temporary file in the buffer, and if so, the verification is started. Optionally, it can be determined whether there is a temporary file with an unfinished upgrade state by reading the file index table of the buffer. Optionally, if the file index table is empty or there is no unfinished upgrade file, the buffer verification is directly skipped, and the recovery area image file verification process is performed.

[0132] Optionally, if there is a temporary file, the upgrade package integrity identifier in the file header is read to determine whether the file is a complete upgrade package. If it is not complete, the temporary file is marked as invalid, and the recovery area image file verification process is performed. Optionally, the hash value of the temporary file can be verified, and the specific method has been described above and will not be described again.

[0133] Optionally, if the temporary file of the buffer passes the verification, the temporary file is used to recover the active area of the first non-volatile memory. Optionally, the platform firmware recovery function is used to decompress the temporary file to extract the firmware image core file therein. The firmware image core file is split according to the physical block size of the active area, and then each data block after the splitting is written into the active area in sequence.

[0134] Optionally, if the check of the temporary file of the buffer fails, the temporary file is kept, the mirror file recovery process of the recovery area is automatically performed, and the information that the buffer recovery fails and the firmware recovery is switched to the recovery area is sent to the BMC.

[0135] The server firmware loading method provided by the embodiment of the application reduces the upgrade operation after the recovery of the active area is completed by preferentially recovering the server firmware of the active area using the temporary file of the buffer.

[0136] As an optional implementation, the method further comprises the following steps based on any one of the above embodiments:

[0137] First, whether the active area of the first non-volatile memory has firmware update is monitored during the process that the server loads the server firmware from the second non-volatile memory.

[0138] Optionally, after the server loads the firmware from the second non-volatile memory and normally runs, whether the active area has firmware update is monitored according to a preset strategy, so that the valid update is avoided.

[0139] Optionally, the data write operation of the active area of the first non-volatile memory can be monitored, such as the write enable signal of the SPI Flash and the data block rewriting record, and the change of the core code segment and the version identification segment is mainly focused on. Optionally, the version identification segment of the active area can be read every 3 minutes, and compared with the cached initial version. If the version changes, it is determined that there is update.

[0140] It should be noted that after the repair completion signal of the active area of the first non-volatile memory is monitored, whether the active area of the first non-volatile memory has firmware update is monitored again.

[0141] Secondly, in response to the monitoring that the active area of the first non-volatile memory has firmware update, the server firmware of the updated active area is checked based on the platform firmware recovery function.

[0142] Optionally, when it is determined that the active area has firmware update, the updated active area firmware is comprehensively checked to ensure that the updated firmware is not damaged and tampered. It should be noted that the checking method of the server firmware of the active area has been described above and will not be described here.

[0143] Finally, in the case that the server firmware of the updated active area passes the check, a switching instruction is sent to the server, and the server is switched to load the server firmware from the active area of the first non-volatile memory.

[0144] Optionally, if the updated active area firmware passes verification, a switching instruction is sent to the server's firmware loading control module. The switching instruction includes the target loading source and the switching timing. The target loading source is the active area of ​​the first non-volatile memory; the switching timing is after the current firmware loading cycle ends, such as waiting for the current process to complete its call to the second non-volatile memory firmware to avoid service interruption.

[0145] The server firmware loading method provided in this application embodiment can capture the update status of the active area in real time during the loading of the second non-volatile memory, avoiding the server firmware version lag caused by update delay.

[0146] As an optional implementation, based on any of the above embodiments, the first non-volatile memory further includes a buffer, and the method further includes the following steps:

[0147] First, when the server is in the power-on phase and the server firmware verification of the active area of ​​the first non-volatile memory passes, check whether there is an unsubmitted firmware upgrade package in the buffer of the first non-volatile memory.

[0148] Optionally, the upgrade status table in the buffer, which records the status identifiers of all upgrade packages, can be read to filter out upgrade packages that have not been submitted.

[0149] Optionally, if there is no identifier record corresponding to the unsubmitted upgrade package in the upgrade status table, or the file size of the corresponding upgrade package is 0 bytes, it is determined that there is no valid unsubmitted upgrade package, and the server starts the service normally.

[0150] Secondly, if there is an unsubmitted firmware upgrade package in the buffer of the first non-volatile memory, the firmware upgrade package is verified by signature and hash value.

[0151] Optionally, for upgrade packages that have not been submitted, the platform's firmware recovery function can be used to perform signature verification and hash value verification to ensure that the upgrade package has not been tampered with or corrupted. It should be noted that the methods for signature verification and hash value verification of data have been described above and will not be repeated here.

[0152] Optionally, the unsubmitted upgrade package is deemed valid only if both signature verification and hash value verification pass. If either signature verification or hash value verification fails, an invalid message indicating that the unsubmitted upgrade package is not valid is sent to the BMC, the invalid packets in the buffer are cleared, and the server starts operations normally.

[0153] Finally, if both the firmware upgrade package signature verification and hash value verification pass, the firmware upgrade package is written to the active area of ​​the first non-volatile memory, and the server is restarted.

[0154] Optionally, if the check of the unsubmitted upgrade package passes, the platform firmware recovery function performs active area writing and server restart operations to ensure that the upgrade package is completely written and takes effect.

[0155] Optionally, the firmware core image in the unsubmitted upgrade package is decompressed, and unnecessary components such as upgrade scripts and interrupt markers in the unsubmitted upgrade package are excluded. The firmware core image is split according to the physical block size of the active area, and is sequentially written from the starting address of the active area.

[0156] Optionally, after the firmware core image of the unsubmitted upgrade package is written successfully, the server can be restarted immediately. After the server is restarted, the firmware of the active area can be checked. If the firmware check passes, it can be determined that the unsubmitted upgrade package processing is completed, and the unsubmitted upgrade package in the buffer area is cleared.

[0157] The loading method for server firmware provided by the embodiment of the application checks the firmware upgrade package and upgrades the server firmware of the active area using the firmware upgrade package after the check passes when there is an unsubmitted firmware upgrade package in the buffer area, thereby avoiding function loss or security vulnerabilities caused by long-term operation of the old version of the server.

[0158] As an optional implementation, on the basis of any one of the above embodiments, the following steps are further included.

[0159] First, in response to the server firmware check of the active area failing, a server restart operation is triggered, and the server is restarted.

[0160] Optionally, when the server firmware check of the active area fails, the check failure reason can be a hardware problem such as active area address access error, physical block bad block ratio ≥ 5%, and bus communication interruption. At this time, server restart can solve the above hardware problems.

[0161] Optionally, the restart trigger is not more than 2 times within the same boot cycle, to avoid falling into a dead loop of constant check failure.

[0162] Optionally, during the server restart, the state of the server core hardware is monitored in real time. If a "restart interruption", "hardware initialization failure" or the like occurs, the restart is terminated immediately.

[0163] Secondly, after the server is restarted, the server firmware of the active area of the first non-volatile memory is checked again based on the platform firmware recovery function.

[0164] Specifically, after the server completes the restart, the platform firmware recovery function re-verifies the server firmware of the active area of the first non-volatile memory. Optionally, if the server firmware of the active area passes the re-verification, it is determined that the first verification failure is a temporary fault, a temporary fault recovery notification is sent to the BMC, and the server normally loads the server firmware from the active area of the first non-volatile memory.

[0165] Finally, in the case that the re-verification of the server firmware of the active area of the first non-volatile memory fails, the active area is recovered based on the platform firmware recovery function, and a switching instruction is sent to the server to make the server load the server firmware from the second non-volatile memory during the recovery.

[0166] Optionally, if the server firmware of the active area still fails the re-verification, the active area is recovered based on the platform firmware recovery function, and a switching instruction is sent to the server to make the server load the server firmware from the second non-volatile memory during the recovery.

[0167] The server firmware loading method provided by the embodiment of the application can exclude temporary faults by restarting, and avoid unnecessary recovery of normal server firmware.

[0168] Figure 5 A structural schematic diagram of a server firmware loading device provided by an embodiment of the application is shown in FIG. 1. As shown in the figure, the server firmware loading device provided by the embodiment is located in an electronic device. The server firmware loading device 50 provided by the embodiment comprises a verification module 51, a firmware recovery and instruction sending module 52, an acquisition module 53, and a switching judgment module 54. Figure 5

[0169] Specifically, the verification module 51 is configured to verify the server firmware of the active area of the first non-volatile memory based on the platform firmware recovery function in the case that the server is in a booting stage; wherein the active area is configured to store the server firmware. The firmware recovery and instruction sending module 52 is configured to recover the server firmware of the active area based on the platform firmware recovery function and send a switching instruction to the server in response to the verification of the server firmware of the active area failing. The switching instruction is configured to instruct the server to load the server firmware from the second non-volatile memory during the recovery of the server firmware of the active area. The acquisition module 53 is configured to acquire the version number of the server firmware of the active area and the version number of the server firmware in the second non-volatile memory in the case that the recovery of the server firmware of the active area is completed. The switching judgment module 54 is configured to judge the version number of the server firmware of the active area and the version number of the server firmware in the second non-volatile memory based on a preset judgment strategy, and make the server load the server firmware from the first non-volatile memory or the second non-volatile memory according to the judgment result.​

[0170] Optionally, the switching judgment module 54, in the process of judging the version number of the server firmware in the active area and the version number of the server firmware in the second non-volatile memory based on the preset judgment strategy, and causing the server to load the server firmware from the first non-volatile memory or the second non-volatile memory according to the judgment result, is specifically configured to: in the case that the version number of the server firmware in the second non-volatile memory is higher than the version number of the server firmware in the active area of the first non-volatile memory, causing the server to keep loading the server firmware from the second non-volatile memory; in the case that the version number of the server firmware in the first non-volatile memory is higher than the version number of the server firmware in the active area of the second non-volatile memory, sending a switching instruction to the server, and causing the server to switch to loading the server firmware from the active area of the first non-volatile memory.

[0171] Optionally, the switching judgment module 54, in the process of judging the version number of the server firmware in the active area and the version number of the server firmware in the second non-volatile memory based on the preset judgment strategy, and causing the server to load the server firmware from the first non-volatile memory or the second non-volatile memory according to the judgment result, is specifically configured to: obtaining a historical version number of the server firmware loaded by the server during the last normal operation; determining a first difference degree between the version number of the server firmware in the active area of the first non-volatile memory and the historical version number, and a second difference degree between the version number of the server firmware in the second non-volatile memory and the historical version number; in the case that the first difference degree is less than or equal to the second difference degree, sending a switching instruction to the server, and causing the server to switch to loading the server firmware from the active area of the first non-volatile memory; in the case that the first difference degree is greater than the second difference degree, causing the server to keep loading the server firmware from the second non-volatile memory.

[0172] Optionally, the checking module 51, in the process of checking the server firmware in the active area of the first non-volatile memory based on the platform firmware recovery function, is specifically configured to: obtaining a key, region data of the active area, and signature data; determining a first hash value corresponding to the active area according to the key and the region data, and determining a second hash value corresponding to the active area according to the region data and the signature data; comparing the first hash value and the second hash value; in the case that the first hash value is the same as the second hash value, determining that the checking of the server firmware in the active area of the first non-volatile memory is passed; in the case that the first hash value is not the same as the second hash value, determining that the checking of the server firmware in the active area of the first non-volatile memory is failed.

[0173] Optionally, the checking module 51, when checking the server firmware of the active area of the first non-volatile memory based on the platform firmware recovery function, is specifically configured to: divide the server firmware of the active area into a plurality of data blocks, and perform checking calculation on the plurality of data blocks respectively by using a plurality of threads; after each thread completes the checking calculation, obtain the checking result of each data block; and when the checking of each data block is passed, determine that the checking of the server firmware of the active area of the first non-volatile memory is passed.

[0174] Optionally, the first non-volatile memory further includes a recovery area, and the recovery area is configured to store the mirror file of the server firmware.

[0175] Optionally, the firmware recovery and instruction sending module 52, when performing recovery on the server firmware of the active area based on the platform firmware recovery function in response to the checking of the server firmware of the active area being failed, is specifically configured to: in response to the checking of the server firmware of the active area being failed, check the mirror file of the recovery area of the first non-volatile memory; and when the checking of the mirror file of the recovery area is passed, perform recovery on the server firmware of the active area by using the mirror file of the recovery area based on the platform firmware recovery function.

[0176] Optionally, the first non-volatile memory further includes a recovery area, and the recovery area is configured to store the mirror file of the server firmware.

[0177] Optionally, the firmware recovery and instruction sending module 52, when checking the mirror file of the recovery area of the first non-volatile memory in response to the checking of the server firmware of the active area being failed, is specifically configured to: when the checking of the mirror file of the recovery area is failed, obtain the backup mirror of the server firmware in the second non-volatile memory; perform hash value checking and signature verification on the backup mirror, and when the checking of the backup mirror is passed, write the backup mirror into the recovery area of the first non-volatile memory, and perform recovery on the server firmware of the active area based on the backup mirror of the recovery area.

[0178] Optionally, the first non-volatile memory further includes a recovery area and a buffer area, the recovery area is configured to store the mirror file of the server firmware, and the buffer area is configured to store a temporary file for server firmware upgrade.

[0179] Optionally, the firmware recovery and instruction sending module 52, in response to the server firmware of the active area failing the verification, recovers the server firmware of the active area based on the platform firmware recovery function, is specifically used for: in response to the server firmware of the active area failing the verification, verifying the temporary file of the server firmware upgrade of the buffer area of the first non-volatile memory; in the case that the temporary file of the buffer area passes the verification, recovering the server firmware of the active area based on the platform firmware recovery function using the temporary file of the buffer area; in the case that the temporary file of the buffer area fails the verification, recovering the active area based on the platform firmware recovery function using the mirror file of the recovery area.

[0180] Optionally, the server firmware loading device further comprises a monitoring module.

[0181] Optionally, the monitoring module is used for monitoring whether the active area of the first non-volatile memory has firmware update during the process that the server loads the server firmware from the second non-volatile memory; the verifying module 51 is further used for verifying the updated server firmware of the active area based on the platform firmware recovery function in response to monitoring that the active area of the first non-volatile memory has firmware update; the firmware recovery and instruction sending module 52 is further used for sending a switching instruction to the server in the case that the updated server firmware of the active area passes the verification, and the server switches to load the server firmware from the active area of the first non-volatile memory.

[0182] Optionally, the first non-volatile memory further comprises a buffer area.

[0183] Optionally, the server firmware loading device further comprises a detecting module.

[0184] Optionally, the detecting module is used for: in the case that the server is in the booting stage and the server firmware of the active area of the first non-volatile memory passes the verification, detecting whether there is an uncommitted firmware upgrade package in the buffer area of the first non-volatile memory; in the case that there is an uncommitted firmware upgrade package in the buffer area of the first non-volatile memory, verifying the signature and the hash value of the firmware upgrade package; in the case that the signature verification and the hash value verification of the firmware upgrade package both pass, writing the firmware upgrade package into the active area of the first non-volatile memory, and restarting the server.

[0185] Optionally, the checking module 51 is further configured to: in response to the server firmware in the active area failing to pass the checking, trigger a restart operation of the server, and the server is restarted; after the server is restarted, the server firmware in the active area of the first nonvolatile memory is checked again based on a platform firmware recovery function; and in a case where the server firmware in the active area of the first nonvolatile memory fails to pass the checking again, the active area is recovered based on the platform firmware recovery function, and a switching instruction is sent to the server to enable the server to load the server firmware from the second nonvolatile memory during the recovery.

[0186] It should be noted that the technical effects of the server firmware loading apparatus provided in the embodiment have been explained in the above method embodiments, and thus will not be repeated here.

[0187] Figure 6 A structural schematic diagram of an electronic device provided in an embodiment of the present application is shown in FIG. 6, and an electronic device 60 provided in an embodiment of the present application includes a memory 61 and a processor 62. Figure 6

[0188] The memory 61 stores a computer program, and the processor 62 is configured to run the computer program to perform the steps in any of the above server firmware loading method embodiments.

[0189] An embodiment of the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program.

[0190] In an example embodiment, the above computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0191] An embodiment of the present application further provides a computer program product, and the above computer program product includes a computer program.

[0192] An embodiment of the present application further provides another computer program product, and the computer program product includes a non-volatile computer readable storage medium.

[0193] ​Those skilled in the art will further realize that the mere concepts, teachings, and embodiments described herein are merely meant to provide an enabling description of the applications and are not intended to limit the scope of the applications. Therefore, embodiments or examples described herein are not meant to be limiting, but merely to aid in the understanding of the overall more complete disclosure of the applications. Accordingly, those skilled in the art will recognize that modifications and variations of the more complete description herein can be resorted to without departing from the spirit and scope of the applications. Therefore, it is intended that the applications encompass all such modifications and variations as fall within the scope of the applications. All articles, patents, and other publications that have been cited herein are incorporated herein by reference in their entirety.

[0194] The above has carried out the detailed introduction to the scheme provided by the present application. The principle and implementation of the present application are described by applying specific examples in this paper. The above example description is only applicable to help understand the method and core idea of the present application. It should be pointed out that for ordinary skilled in the art, some improvements and modifications can be made to the present application without departing from the principle of the present application. These improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method for loading server firmware, characterized in that, include: When the server is in the power-on phase, the server firmware in the active area of ​​the first non-volatile memory is verified based on the platform firmware recovery function; wherein, the active area is used to store the server firmware. In response to the server firmware verification failing in the active area, the server firmware in the active area is restored based on the platform firmware recovery function, and a switching instruction is sent to the server; wherein, the switching instruction is used to instruct the server to load the server firmware from the second non-volatile memory during the server firmware recovery in the active area. Once the server firmware in the active area has been restored, obtain the version number of the server firmware in the active area and the version number of the server firmware in the second non-volatile memory. Retrieve the historical version number of the server firmware loaded during the last normal operation on the server; A first degree of difference between the version number of the server firmware in the active area of ​​the first non-volatile memory and the historical version number, and a second degree of difference between the version number of the server firmware in the second non-volatile memory and the historical version number are determined. If the first difference degree is less than or equal to the second difference degree, a switching instruction is sent to the server, and the server switches to loading server firmware from the active area of ​​the first non-volatile memory. If the first difference is greater than the second difference, the server continues to load server firmware from the second non-volatile memory; The first non-volatile memory further includes a recovery area and a buffer. The recovery area is used to store the image file of the server firmware, and the buffer is used to store temporary files for server firmware upgrades. The restoration of the server firmware in the active zone based on the platform firmware recovery function includes: In response to the server firmware verification failing in the active area, the temporary file for server firmware upgrade in the buffer of the first non-volatile memory is verified. If the temporary file in the buffer passes verification, the server firmware in the active area is restored using the temporary file in the buffer based on the platform firmware recovery function. If the temporary file verification in the buffer fails, the active area is restored using the image file of the recovery area based on the platform firmware recovery function. Also includes: During the process of the server loading server firmware from the second non-volatile memory, the active area of ​​the first non-volatile memory is monitored to see if there is a firmware update. In response to the detection of a firmware update in the active area of ​​the first non-volatile memory, the server firmware of the updated active area is verified based on the platform firmware recovery function. If the updated server firmware in the active area passes verification, a switching command is sent to the server, which switches to loading the server firmware from the active area of ​​the first non-volatile memory.

2. The method according to claim 1, characterized in that, The verification of the server firmware in the active area of ​​the first non-volatile memory based on the platform firmware recovery function includes: Obtain the key, the region data of the active area, and the signature data; The first hash value corresponding to the active area is determined based on the key and the area data, and the second hash value corresponding to the active area is determined based on the area data and the signature data. Compare the first hash value and the second hash value; If the first hash value is the same as the second hash value, the server firmware verification of the active area of ​​the first non-volatile memory is determined to be successful. If the first hash value and the second hash value are different, the server firmware verification of the active area of ​​the first non-volatile memory fails.

3. The method according to claim 1, characterized in that, The verification of the server firmware in the active area of ​​the first non-volatile memory based on the platform firmware recovery function includes: The server firmware of the active area is divided into multiple data blocks, and multiple threads are used to perform verification calculations on the multiple data blocks respectively. After each thread has completed the verification calculation, the verification result of each data block is obtained; If the verification of each of the data blocks passes, it is determined that the server firmware verification of the active area of ​​the first non-volatile memory has passed.

4. The method according to any one of claims 1-3, characterized in that, The first non-volatile memory further includes a buffer, and the method further includes: When the server is in the power-on phase and the server firmware verification of the active area of ​​the first non-volatile memory passes, check whether there is an unsubmitted firmware upgrade package in the buffer of the first non-volatile memory. If there is an unsubmitted firmware upgrade package in the buffer of the first non-volatile memory, the firmware upgrade package is subject to signature verification and hash value verification. If both the firmware upgrade package signature verification and hash value verification pass, the firmware upgrade package is written to the active area of ​​the first non-volatile memory, and the server is restarted.

5. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the server firmware loading method as described in any one of claims 1-4 when executing the computer program.

Images