BMC startup, BMC firmware compilation, BMC firmware upgrade method, chip and computing device

Abstract

The embodiment of the application provides a BMC starting, BMC firmware compiling upgrading, BMC firmware upgrading method, chip and computing device, and relates to the technical field of computers. The method is applied to a first BMC, the first BMC comprises a security core, a business core and a first memory, the target firmware is stored in the first memory, the target firmware comprises a first security core firmware and a first version number file, the first version number file is used for indicating the version number of firmware not supported by the security core, or the first version number file is used for indicating the version number of firmware supported by the security core, and the method comprises the following steps: obtaining the target firmware; obtaining the first security core firmware and the first version number file according to the target firmware; obtaining a first version number set according to the first version number file; storing the first version number set to a second memory and running the first security core firmware, the second memory does not allow the business core to access, so that the security protection of the BMC is realized through the first version number file which is not easy to be maliciously tampered.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a baseboard management controller (BMC) starting method, a BMC firmware compiling method, a BMC firmware upgrading method, a chip and a computing device. BACKGROUND

[0002] A BMC (Baseboard Management Controller) is a management system of a computing device (for example, a server) and is used for monitoring and managing the computing device connected thereto (or integrated therein). The BMC provides rich management control services for the computing device, but also has security threats.

[0003] For example, in some example scenarios, as various types of hardware develop and various types of hardware and chip manufacturing processes are updated and upgraded, at least part of the BMC hardware in the BMC can be updated and upgraded. For the updated and upgraded BMC hardware, its driver program can be different from the driver program of the BMC hardware before the update and upgrade, and the previous driver version cannot run. For the above-mentioned situation, if the updated and upgraded BMC hardware is driven based on the driver program of the BMC hardware before the update and upgrade, the updated and upgraded BMC hardware can be damaged. Therefore, when the BMC firmware is upgraded, the firmware upgrade anti-backoff needs to be performed to prevent the upgraded firmware from being incompatible with the updated and upgraded BMC hardware.

[0004] Therefore, how to provide a method capable of better protecting BMC hardware during BMC firmware upgrading is crucial. SUMMARY

[0005] Embodiments of the present application provide a BMC starting method, a BMC firmware compiling method, a BMC firmware upgrading method, an apparatus, a chip, a computing device, a computer storage medium and a computer program product, which can realize the security protection of the BMC.

[0006] In a first aspect, an embodiment of the present application provides a BMC starting method applied to a secure core of a first BMC, wherein the first BMC comprises the secure core, a business core and a first memory, the first memory stores a target firmware, the target firmware comprises a first secure core firmware and a first version number file, the first version number file is used to indicate a version number of a firmware not supported by the secure core, or the first version number file is used to indicate a version number of a firmware supported by the secure core, and the method comprises the following steps:

[0007] obtaining the target firmware;

[0008] obtaining the first secure core firmware and the first version number file according to the target firmware;

[0009] obtaining a first version number set according to the first version number file;

[0010] storing the first version number set to a second memory which does not allow the business core to access, and running the first secure core firmware.

[0011] In the above example, the first BMC includes a secure core and a business core, in the starting process, after obtaining the target firmware from the first memory, the first secure core firmware and the first version number file are determined from the target firmware, and then the first version number set is obtained according to the first version number file, the first version number set is stored in the second memory which does not allow the business core to access, and the first secure core firmware is run, the second memory which does not allow the business core to access can avoid the first version number set stored therein being tampered with by the program run by the business core, and can ensure that the first version number set is secure and reliable, the first version number set is used to indicate the version number of the firmware not supported by the secure core, or the first version number file is used to indicate the version number of the firmware supported by the secure core, and the first BMC can be prevented from being upgraded to the firmware not supported by the secure core through the first version number set, which provides a basis for the safe upgrade of the BMC, and realizes the security protection of the BMC.

[0012] In one possible example, the target firmware further includes a first signature, and the obtaining the first secure core firmware and the first version number file according to the target firmware specifically includes: obtaining the first secure core firmware, the first version number file and the first signature according to the target firmware; and before the obtaining the first version number set according to the version number file, the method further includes: obtaining public key information from a one-time programmable (OTP) memory; verifying the first secure core firmware and the first version number file according to the public key information and the first signature; and when the verification passes, obtaining the first version number set according to the first version number file. In this example, the public key information is stored in the OTP memory, which can ensure the credibility of the public key information, the first secure core firmware and the first version number file are verified for integrity and credibility by using the public key information and the first signature, and the subsequent process is performed after the verification passes, which can better realize the protection of the BMC and avoid the situation that the tampered first secure core firmware and the first version number file are run in the BMC.

[0013] In a possible example, the target firmware further includes a first service core firmware and a second version number file, the second version number file is used to indicate a version number of firmware not supported by the service core, or the second version number file is used to indicate a version number of firmware supported by the service core, and the method further includes: obtaining the first service core firmware and the second version number file according to the target firmware; obtaining a second version number set according to the second version number file; storing the second version number set in the second memory, and running the first service core firmware.

[0014] In the above example, the target firmware further includes a first service core firmware and a second version number file used to indicate a version number of firmware not supported by the service core, or a version number of firmware supported by the service core, and the second version number set obtained according to the second version number file is stored in the second memory, which is difficult to be tampered with, so as to protect the second version number set, and further prevent the first BMC from being upgraded to firmware not supported by the service core through the second version number set, thereby providing further protection for the safe upgrade of the BMC. The first service core firmware is run to provide safe monitoring and management services for the corresponding computing device of the first BMC.

[0015] In a possible example, the target firmware further includes a second signature, and the obtaining the first service core firmware and the second version number file according to the target firmware specifically includes: obtaining the first service core firmware, the second version number file, and the second signature according to the target firmware; and before the obtaining the second version number set according to the version number file, the method further includes: obtaining public key information from one-time programmable (OTP) memory; verifying the first service core firmware and the second version number file according to the public key information and the second signature; and when the verification passes, obtaining the second version number set according to the second version number file. In this example, the public key information is stored in the OTP memory, which can ensure the credibility of the public key information, and the first service core firmware and the second version number file are verified for integrity and credibility by using the public key information and the second signature. After the verification passes, the subsequent process is executed, which can better protect the BMC and avoid the situation that the tampered first service core firmware and the second version number file run in the BMC.

[0016] In a possible example, the target firmware further comprises a second signature, and the obtaining the first service core firmware and the second version number file according to the target firmware comprises: obtaining the first service core firmware, the second version number file and the second signature according to the target firmware; and before the obtaining the second version number set according to the version number file, the method further comprises: obtaining the public key information from the first secure core firmware; verifying the first service core firmware and the second version number file according to the public key information and the second signature; and when the verification is passed, obtaining the second version number set according to the second version number file.

[0017] In this example, the public key information is stored in the first secure core firmware, and after the verification of the first secure core firmware is passed, the public key information is also passed. Subsequently, the public key information that is passed is obtained from the first secure core firmware, and the first service core firmware and the second version number file are verified according to the public key information and the second signature, which can ensure the credibility of the verification result. Then, when the verification is passed, the subsequent process is executed, which can better protect the BMC and avoid the situation that the tampered first service core firmware and the second version number file run in the BMC.

[0018] In a possible example, the method further comprises: in response to an upgrade instruction, obtaining a second secure core firmware and a first version number to be verified in an upgrade package, the first version number to be verified being a version number of the second secure core firmware; obtaining the first version number set from the second memory; verifying the second secure core firmware based on the first version number set and the first version number to be verified; and if the verification is successful, upgrading the first secure core firmware to the second secure core firmware. In this example, before the upgrade, the second secure core firmware is verified according to the first version number set in the second memory and the first version number to be verified in the upgrade package. It is determined whether the second secure core firmware is a secure core executable firmware of the first BMC. If the verification is successful, it is determined that the second secure core firmware is a secure core executable firmware, and the first secure core firmware is upgraded to the second secure core firmware, so as to realize the secure upgrade of the BMC and protect the hardware of the BMC.

[0019] In a possible example, the verifying the second secure core firmware based on the first version number set and the first to-be-verified version number specifically comprises: when the first to-be-verified version number is different from all version numbers in the first version number set, determining that the verifying succeeds, where the first version number set comprises version numbers of at least one firmware that is not supported by the secure core; or when the first to-be-verified version number is the same as any one version number in the first version number set, determining that the verifying succeeds, where the first version number set comprises version numbers of at least one firmware that is supported by the secure core. In this example, two implementation manners of determining the verifying result are provided, so that the firmware that is not supported by the secure core is avoided to be upgraded, and the security of the BMC hardware is ensured.

[0020] In a possible example, the verifying the second secure core firmware based on the first version number set and the first to-be-verified version number specifically comprises: when the first to-be-verified version number is greater than or equal to version numbers in the first version number set, determining that the verifying succeeds, where the first version number set comprises minimum version numbers of firmware that is supported by the secure core; or when the first to-be-verified version number is greater than version numbers in the first version number set, determining that the verifying succeeds, where the first version number set comprises maximum version numbers of firmware that is not supported by the secure core. In this example, two implementation manners of determining the verifying result are provided, so that the firmware that is not supported by the secure core is avoided to be upgraded, and the security of the BMC hardware is ensured.

[0021] In the above example, the verifying the second secure core firmware based on the first version number set and the first to-be-verified version number specifically comprises: when the type identifier of the first BMC is the same as a type identifier of a BMC in the first version number set, and the first to-be-verified version number is different from all version numbers corresponding to the type identifier of the BMC in the first version number set, determining that the verifying succeeds, where the first version number set comprises type identifiers of at least one BMC and version numbers of at least one firmware that is not supported by the secure core corresponding to different BMC type identifiers; or when the type identifier of the first BMC is the same as a type identifier of a BMC in the first version number set, and the first to-be-verified version number is the same as any one version number corresponding to the type identifier of the BMC in the first version number set, determining that the verifying succeeds, where the first version number set comprises type identifiers of at least one BMC and version numbers of at least one firmware that is supported by the secure core corresponding to different BMC type identifiers.

[0022] In the above examples, the first version number set includes at least one type identifier of the BMC and version numbers of at least one firmware not supported by the security core corresponding to different BMC type identifiers, or the first version number set includes at least one type identifier of the BMC and version numbers of at least one firmware supported by the security core corresponding to different BMC type identifiers. The type identifier of the BMC can identify version information of the BMC. The first version number set can indicate version numbers of at least one firmware not supported or supported by the BMC corresponding to a type identifier (version). The first version number set can be used for finer-grained protection of the BMC.

[0023] In one possible example, the checking of the second security core firmware based on the first version number set and the first to-be-checked version number specifically includes: when the type identifier of the first BMC is the same as the type identifier of a BMC in the first version number set, and the first to-be-checked version number is greater than or equal to the version number corresponding to the BMC type in the first version number set, it is determined that the checking is successful, where the first version number set includes at least one type identifier of the BMC and minimum version numbers of firmware supported by the security core corresponding to different BMC type identifiers; or when the type identifier of the first BMC is the same as the type identifier of a BMC in the first version number set, and the first to-be-checked version number is greater than the version number corresponding to the BMC type in the first version number set, it is determined that the checking is successful, where the first version number set includes at least one type identifier of the BMC and maximum version numbers of firmware not supported by the security core corresponding to different BMC type identifiers.

[0024] In the above examples, the first version number set includes at least one type identifier of the BMC and minimum version numbers of firmware supported by the security core corresponding to different BMC type identifiers, or includes at least one type identifier of the BMC and maximum version numbers of firmware not supported by the security core corresponding to different BMC type identifiers. The type identifier of the BMC can identify version information of the BMC. The first version number set can indicate minimum version numbers of firmware supported by the security core or maximum version numbers of firmware not supported by the security core corresponding to a type identifier (version) of the BMC. The first version number set can be used for finer-grained protection of the BMC.

[0025] In a second aspect, an embodiment of the present application provides a BMC firmware compiling method, including:

[0026] obtaining a first security core firmware and a first version number set, where the first version number set is used to indicate version numbers of firmware not supported by a security core of a first BMC, or the first version number set is used to indicate version numbers of firmware supported by the security core;

[0027] generating a first spliced firmware according to the first secure core firmware and the first version number set;

[0028] determining a header of the target firmware, the header comprising location information of the first version number set;

[0029] generating the target firmware according to the header and the first spliced firmware.

[0030] In the above example, based on the version number of the firmware that is not supported by the secure core, or the first version number set used to indicate the version number of the firmware supported by the secure core, the first secure core firmware generates the first spliced firmware, and then the target firmware including the first version number set is generated according to the header containing the location information of the first version number set and the first spliced firmware, thereby providing a basis for subsequent security upgrade of the BMC and providing a basis for protecting the BMC hardware.

[0031] In one possible example, after the first spliced firmware is generated according to the first secure core firmware and the first version number set, the method further comprises: signing the first spliced firmware using a first private key to obtain a first signature; and generating the target firmware according to the header, the first spliced firmware and the first signature. In this example, the first spliced firmware is signed to obtain the first signature, and the target firmware is generated according to the header, the first spliced firmware and the first signature, so that when the BMC starts the target firmware, the security and integrity of the first spliced firmware can be authenticated based on the first signature, thereby providing a basis for secure start of the BMC.

[0032] In one possible example, before the target firmware is generated according to the header and the first spliced firmware, the method further comprises: obtaining the first business core firmware and a second version number set, the second version number set being used to indicate the version number of the firmware that is not supported by the business core of the first BMC, or the first version number set being used to indicate the version number of the firmware supported by the business core; generating a second spliced firmware according to the first business core firmware and the second version number set; determining the header of the target firmware, the header comprising location information of the first version number set and location information of the second version number set; and generating the target firmware according to the header, the first spliced firmware and the second spliced firmware.

[0033] In the above example, the target firmware is generated according to the first service core firmware and the second version number set, and the header and the first spliced firmware, to obtain the target firmware carrying the first version number set and the second version number set, to provide a basis for implementing the security upgrade of the BMC based on the target firmware, and further to provide a basis for protecting the BMC hardware.

[0034] In one possible example, after the second spliced firmware is generated according to the first service core firmware and the second version number set, the method further includes: signing the second spliced firmware using a second private key to obtain a second signature; and generating the target firmware according to the header, the first spliced firmware and the second spliced firmware, specifically including: generating the target firmware according to the header, the first spliced firmware, the first signature, the second spliced firmware and the second signature.

[0035] In the above example, the second signature is obtained by signing the second spliced firmware, and the target firmware is generated according to the header, the first spliced firmware, the first signature, the second spliced firmware and the second signature, so that when the BMC starts the target firmware, the security and integrity of the first spliced firmware can be authenticated based on the first signature, and the security and integrity of the second spliced firmware can be authenticated based on the second signature, to provide a basis for the secure start of the BMC.

[0036] In one possible example, the first spliced firmware is generated according to the first security core firmware and the first version number set, specifically including: compiling the first version number set into the first version number file, the first version number file being in a binary format. In one possible implementation, the first version number file can also be spliced at the end of the first security core firmware to obtain the first spliced firmware. In this example, in order to facilitate the user to compile the first version number set, a service of compiling the first version number set in a text form is provided for the user, in order to facilitate the running of the BMC, the first version number set is compiled into the first version number file in a binary format, and then the first version number file is spliced at the end of the first security core firmware to obtain the first spliced firmware. In this way, the user is facilitated, the compiling efficiency of the first version number set is improved, and the normal running of the firmware is ensured.

[0037] In one possible example, the generating the second spliced firmware according to the first service core firmware and the second version number set specifically comprises: compiling the second version number set into a second version number file in binary format; and splicing the second version number file at the end of the first service core firmware to obtain the second spliced firmware. In this example, in order to facilitate the user to compile the second version number set, a service of compiling the second version number set in text form into a second version number file in binary format is provided for the user, and in order to facilitate the running of the BMC, the second version number file is spliced at the end of the first service core firmware to obtain the second spliced firmware. In this way, the convenience for the user is provided, the compiling efficiency of the second version number set is improved, and the normal running of the firmware is ensured.

[0038] In a third aspect, an embodiment of the present application provides a BMC firmware upgrading method, which is applied to a first BMC, the first BMC comprising a security core, a service core and a second memory, the security core running a first security core firmware, the second memory storing a first version number set, the first version number set being used to indicate a version number of a firmware that is not supported by the security core, or the first version number set being used to indicate a version number of a firmware that is supported by the security core, the second memory not allowing the service core to access, and the method comprising:

[0039] In response to an upgrading instruction, obtaining a second security core firmware and a first to-be-verified version number in an upgrading package, the first to-be-verified version number being a version number of the second security core firmware;

[0040] Obtaining the first version number set from the second memory;

[0041] Based on the first version number set and the first to-be-verified version number, verifying the second security core firmware;

[0042] If the verification is successful, upgrading the first security core firmware to the second security core firmware.

[0043] In the embodiment, when the first BMC is upgraded, the second security core firmware to be upgraded is verified first, that is, whether the security core of the first BMC can support (i.e., run and use) the second security core firmware is verified through the first version number set stored in the second memory and the first to-be-verified version number. If the verification is successful, it is determined that the security core of the first BMC can support the second security core firmware, and at this time, the first security core firmware of the first BMC is upgraded to the second security core firmware, so as to realize the secure upgrading of the BMC and avoid the upgrading to a firmware that may damage the hardware of the BMC. Moreover, the second memory does not allow the service core to access, which can better improve the credibility and security of the first version number set and avoid the tampering of the first version number set.

[0044] In a possible example, the verifying the second secure core firmware based on the first version number set and the first to-be-verified version number specifically comprises: when the first to-be-verified version number is different from all version numbers in the first version number set, determining that the verifying is successful, wherein the first version number set comprises version numbers of at least one firmware that is not supported by the secure core; or when the first to-be-verified version number is the same as any one version number in the first version number set, determining that the verifying is successful, wherein the first version number set comprises version numbers of at least one firmware that is supported by the secure core; or when the first to-be-verified version number is greater than or equal to version numbers in the first version number set, determining that the verifying is successful, wherein the first version number set comprises minimum version numbers of firmware that is supported by the secure core; or when the first to-be-verified version number is greater than version numbers in the first version number set, determining that the verifying is successful, wherein the first version number set comprises maximum version numbers of firmware that is not supported by the secure core.

[0045] In this example, different verification passing (success) determination manners are set according to different first version number sets, to ensure the accuracy of the verification result, and to better achieve better security protection of the BMC.

[0046] In a possible example, the business core runs a first business core firmware, and the second memory further stores a second version number set, the second version number set being used to indicate version numbers of firmware that is not supported by the business core, or the second version number set being used to indicate version numbers of firmware that is supported by the business core, and the method further comprises: obtaining a second business core firmware and a second to-be-verified version number in an upgrade package, the second to-be-verified version number being a version number of the second business core firmware; obtaining the second version number set from the second memory; verifying the second business core firmware based on the second version number set and the second to-be-verified version number; and if the verifying is successful, upgrading the first business core firmware to the second business core firmware.

[0047] In this example, the second memory further stores a second version number set, and when the second business core firmware is upgraded, the version of the second business core firmware also needs to be verified based on the second version number set and the second to-be-verified version number, and only when the verifying is successful, the first business core firmware is upgraded to the second business core firmware, to further ensure the security of the BMC.

[0048] In a possible example, the verifying the second service core firmware based on the second version number set and the second to-be-verified version number specifically comprises: when the second to-be-verified version number is different from all version numbers in the second version number set, determining that the verification is successful, wherein the second version number set comprises version numbers of at least one firmware that is not supported by the service core; or when the second to-be-verified version number is the same as any one version number in the second version number set, determining that the verification is successful, wherein the second version number set comprises version numbers of at least one firmware that is supported by the service core; or when the second to-be-verified version number is greater than or equal to version numbers in the second version number set, determining that the verification is successful, wherein the second version number set comprises a minimum version number of firmware that is supported by the service core; or when the second to-be-verified version number is greater than version numbers in the second version number set, determining that the verification is successful, wherein the second version number set comprises a maximum version number of firmware that is not supported by the service core.

[0049] In this example, different verification passing (success) determination manners are set according to different second version number sets, to ensure the accuracy of the verification result, and to better achieve better security protection of the BMC.

[0050] In a fourth aspect, an embodiment of the present application provides a device for starting a baseboard management controller (BMC), which is deployed in a first BMC. The first BMC comprises a security core, a service core and a first memory. The first memory stores a target firmware, which comprises a first security core firmware and a first version number file. The first version number file is used to indicate version numbers of firmware that is not supported by the security core, or the first version number file is used to indicate version numbers of firmware that is supported by the security core. The device comprises:

[0051] A first obtaining module is configured to obtain the target firmware.

[0052] A first obtaining module is configured to obtain the target firmware.

[0053] A second obtaining module is configured to obtain a first version number set according to the first version number file.

[0054] A storage and running module is configured to store the first version number set to a second memory and run the first security core firmware. The second memory does not allow the service core to access.

[0055] In a fifth aspect, an embodiment of the present application provides a device for compiling a BMC firmware, which comprises:

[0056] The second obtaining module is configured to obtain a first secure core firmware and a first version number set, wherein the first version number set is used to indicate version numbers of firmware that is not supported by the secure core, or the first version number set is used to indicate version numbers of firmware that is supported by the secure core.

[0057] The first generating module is configured to generate a first spliced firmware according to the first secure core firmware and the first version number set.

[0058] The determining module is configured to determine a header of a target firmware, wherein the header comprises position information of the first version number set.

[0059] The second generating module is configured to generate the target firmware according to the header and the first spliced firmware.

[0060] In a sixth aspect, an embodiment of the present application provides a BMC firmware upgrading apparatus deployed in a first BMC, wherein the first BMC comprises a secure core, a business core and a second memory, the secure core runs a first secure core firmware, the second memory stores a first version number set, the first version number set is used to indicate version numbers of firmware that is not supported by the secure core, or the first version number set is used to indicate version numbers of firmware that is supported by the secure core, and the second memory does not allow the business core to access, and the apparatus comprises:

[0061] The second obtaining module is configured to obtain a second secure core firmware and a first to-be-verified version number in an upgrading package in response to an upgrading instruction, wherein the first to-be-verified version number is a version number of the second secure core firmware.

[0062] The third obtaining module is configured to obtain the first version number set from the second memory.

[0063] The first verifying module is configured to verify the second secure core firmware based on the first version number set and the first to-be-verified version number.

[0064] The upgrading module is configured to upgrade the first secure core firmware to the second secure core firmware if the verification is successful.

[0065] In a seventh aspect, an embodiment of the present application provides a chip, which is used to execute the method described in the first aspect or any possible implementation manner of the first aspect or execute the method described in the third aspect or any possible implementation manner of the third aspect.

[0066] In an eighth aspect, an embodiment of the present application provides a computing device, which comprises a central processing unit and a third memory, wherein the central processing unit is used to execute a computer program stored on the third memory to execute the method described in the second aspect or any possible implementation manner of the second aspect.

[0067] In a ninth aspect, an embodiment of the present application provides a computing device, the computing device comprising a central processor and a BMC, the BMC being configured to perform the method described in the first aspect or any possible implementation of the first aspect, or perform the method described in the third aspect or any possible implementation of the third aspect.

[0068] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium storing a computer program, when the computer program is executed on a processor, causing the processor to perform the method described in the first aspect or any possible implementation of the first aspect, or perform the method described in the second aspect or any possible implementation of the second aspect, or perform the method described in the third aspect or any possible implementation of the third aspect.

[0069] In an eleventh aspect, an embodiment of the present application provides a computer program product, characterized in that, when the computer program product is executed on a processor, causing the processor to perform the method described in the first aspect or any possible implementation of the first aspect, or perform the method described in the second aspect or any possible implementation of the second aspect, or perform the method described in the third aspect or any possible implementation of the third aspect.

[0070] It can be understood that the beneficial effects of the above-mentioned fourth aspect to eleventh aspect can refer to the related description in the above-mentioned first aspect, second aspect and / or third aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0071] Figure 1A is a schematic diagram of the upgrading process of the BMC firmware of the BMC;

[0072] Figure 1B is another schematic diagram of the upgrading process of the BMC firmware of the BMC;

[0073] Figure 2 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0074] Figure 3 is a schematic diagram of the BMC firmware compiling method provided by an embodiment of the present application;

[0075] Figure 4 is a schematic diagram of the BMC starting method provided by an embodiment of the present application;

[0076] Figure 5 is a schematic diagram of the BMC firmware upgrading method provided by an embodiment of the present application;

[0077] Figure 6is another flowchart of a firmware compiling method provided by an embodiment of the present application;

[0078] Figure 7 is a splicing diagram of parts in a target firmware provided by an embodiment of the present application;

[0079] Figure 8 is a flowchart of another BMC starting method provided by an embodiment of the present application;

[0080] Figure 9 is a structural diagram of a BMC starting device provided by an embodiment of the present application;

[0081] Figure 10 is a structural diagram of a BMC firmware upgrading device provided by an embodiment of the present application;

[0082] Figure 11 is a structural diagram of a BMC firmware compiling device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0083] The term "and / or" in the present document is used to describe an association relationship of associated objects, which means that there can be three relationships, for example, A and / or B can mean that there are three cases of A alone, A and B together, and B alone. The symbol " / " in the present document represents an or relationship of associated objects, for example, A / B represents A or B.

[0084] The terms "first" and "second" and the like in the description and claims of the present document are used to distinguish different objects, and are not used to describe a specific order of the objects. For example, the first response message and the second response message are used to distinguish different response messages, and are not used to describe a specific order of the response messages.

[0085] In the description herein, it should be understood that the orientations or positional relationships indicated by the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "circumferential" and the like are based on the orientations or positional relationships shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation.

[0086] In the embodiments of the present application, the word "exemplary" or "for example" is used to mean serving as an example, instance, or illustration. Any embodiment or design presented as "exemplary" or "for example" in the embodiments of the present application is not necessarily to be construed as preferred or advantageous over other embodiments or designs. In fact, a variety of implementations of the embodiments of the present application are possible, and are contemplated to be within the scope of the present application. Accordingly, the word "exemplary" or "for example" is used in the sense of " serving as an example or illustration." Furthermore, implementation of the embodiments of the present application can be in any of stages of development, deployment, maintenance, etc.

[0087] To facilitate understanding of the technical solutions of the embodiments of the present application, the terms involved in the present application are explained as follows.

[0088] BMC (Baseboard Management Controller) is a special controller for monitoring and managing computing devices (such as servers), and can be regarded as a small operating system. The BMC includes two parts of BMC hardware and BMC software (i.e., BMC firmware). The BMC hardware includes, for example, a processor, a memory (for example, the first memory and the second memory mentioned in the embodiments of the present application. It can be understood that the memory included in the BMC is not limited to the first memory and the second memory, and the BMC can also include other memories, for example, the memory can include but is not limited to EMMC, Nor Flash, OTP memory, SRAM, and various types of memories such as DDR), and peripheral circuits. The BMC is independently powered and independently operated. Even if the connected computing device is not powered on (for example, the operating system of the computing device is not powered on), the BMC hardware of the BMC can still operate independently. Different hardware can correspond to different firmware. The firmware is a file that can be upgraded and is burned in the memory of the BMC. When the BMC is powered on, the processor of the BMC automatically reads and loads the firmware corresponding to the BMC hardware from the memory through the peripheral circuit to run the firmware, thereby realizing the monitoring and management of the corresponding computing device.

[0089] In some possible examples, the BMC in the embodiments of the present application includes two processors, namely a security core and a business core. The security core is used to run security start code and security core firmware, and is responsible for security start and firmware verification functions (including verification of the security core firmware and verification of the business core firmware). The business core is used to run business core firmware, and is responsible for management and monitoring related functions of the corresponding computing device (such as a server). The BMC further includes a first memory and a second memory. The first memory can be accessed by the security core and the business core. The second memory is not allowed to be accessed by the business core, so that the data stored therein is safer and is prevented from being maliciously tampered with.

[0090] The BMC firmware (e.g., the subsequent target firmware) corresponding to the dual-processor structure of the BMC can also include a secure core firmware and a business core firmware. The secure core firmware can be run on the secure core to provide a security check service for the business core firmware. The secure core determines that the security check of the business core firmware is passed by running the secure core firmware, and then guides the business core to start running the business core firmware to provide monitoring and management services for the corresponding computing device (e.g., a server).

[0091] SRAM (Static Random-Access Memory) is used to store data. The content stored in the SRAM will be deleted after the BMC is powered off.

[0092] OTP (One Time Programmable) is a type of memory of the MCU (Microcontroller Unit, also known as a single-chip microcomputer). After data (e.g., program code) is written into the OTP memory, it cannot be changed or cleared again.

[0093] DDR (Double Data Rate) memory is used to store data, such as program code running on the business core.

[0094] EMMC (Embedded Multi Media Card) refers to a package composed of a flash memory and a flash memory controller integrated on the same silicon chip. It is a type of non-volatile memory.

[0095] The type identifier (i.e., the value) of the BMC can represent information such as the model, version, and manufacturer of the BMC. For example, different manufacturing processes of the same BMC hardware (e.g., EMMC) have different type identifiers (i.e., values). For example, the type identifiers (i.e., values) of two BMCs are different because at least one memory in each BMC is of a different type (assuming that one BMC is equipped with EMMC and the other BMC is equipped with a flash memory instead of EMMC).

[0096] As mentioned above, in some example scenarios, as the development of various types of hardware and the update of the manufacturing process of various types of hardware and chips, in order to better improve the performance of the BMC and / or reduce the cost of the BMC, at least part of the BMC hardware in the BMC can be updated and upgraded (for example, replacing some memory in the BMC hardware; for example, updating and upgrading the manufacturing process of the BMC chip, replacing the BMC chip with a BMC chip with better manufacturing process; for example, replacing some modules (such as DDR PHY (Double Data Rate Physical Layer)) in the BMC chip to make the performance of the BMC chip better and / or the cost lower, etc.).

[0097] Among them, DDR PHY is a physical layer technology for Double Data Rate (DDR) memory interface. It is an interface standard, mainly used to connect DDR particles and DDR controllers. In a DDR memory system, the DDR PHY is responsible for transmitting control signals and data signals from the controller to the memory, and converting the received response signals back to the appropriate control signals. The BMC with at least part of the BMC hardware updated and upgraded can be referred to as a BMC of different versions; for example, the BMC deployed with a certain memory (such as SRAM) updated and upgraded, and the BMC deployed with the memory not updated and upgraded, can be referred to as a BMC of different versions.

[0098] Considering that for the hardware (hereinafter referred to as new version hardware) updated and upgraded in the BMC, the driving software (hereinafter referred to as old version driving software, which can also be referred to as old version hardware driver) before the hardware is updated and upgraded no longer fits the new version hardware, and the driving software corresponding to the new version hardware needs to be adapted and upgraded, accordingly, the firmware of the BMC needs to be updated and upgraded to realize the adaptation and upgrade of the driving software corresponding to the new version hardware.

[0099] In addition, considering that if the new version hardware is driven by the aforementioned old version driving software, it may also cause damage to the new version hardware, and further damage the substrate where the BMC hardware is located. For such BMC hardware, the firmware upgrade corresponding to the hardware needs to be prevented from rolling back to realize the security protection of the BMC. The prevention of rollback can mean that the upgraded firmware cannot be used, and even may damage its BMC hardware, and then roll back to the firmware before the upgrade.

[0100] In an example scenario, in order to realize the security protection of the BMC, as Figure 1AAs shown, the firmware upgrade process of the BMC can include the following processes: reading a non-secure version number from the OTP area of the BMC, wherein the non-secure version number is a version number of the firmware revoked with respect to the BMC, that is, a version number of the firmware not supported (i.e., unable to run and use, prohibited from upgrading) with respect to the BMC; reading a firmware version number of the BMC firmware to be upgraded from the specified non-volatile memory; determining whether the firmware version number belongs to the read non-secure version number; if it is determined that the firmware version number does not belong to the read non-secure version number, upgrading the BMC firmware to be upgraded; and if it is determined that the firmware version number belongs to the read non-secure version number, prohibiting the upgrade of the BMC firmware to be upgraded, to achieve the effect of preventing rollback. Subsequently, if the BMC firmware to be upgraded also carries a new version number of the firmware to be revoked, the new version number of the firmware to be revoked carried by the BMC firmware to be upgraded is written in the OTP area.

[0101] In the above example scenario, the BMC needs to additionally add an OTP area to store the non-secure version number, which is relatively high in cost. Moreover, since the data written in the OTP area cannot be changed and cleared again, it is easy to cause the OTP area to be full and unable to write a new version number of the firmware to be revoked, which is poor in flexibility.

[0102] In yet another example scenario, as shown in Figure 1B As shown, the firmware upgrade process of the BMC can include the following processes: the BMC obtains a minimum upgradable version number from the DDR area thereof, wherein the firmware corresponding to the version number smaller than the minimum upgradable version number is the firmware not supported (i.e., unable to run and use, prohibited from upgrading) with respect to the BMC, and the minimum upgradable version number can be stored in an XML (Extensible Markup Language) format. The XML is a file in a pure text format, and the XML is a subset of the Standard Generalized Markup Language (SGML) and is a markup language for marking an electronic file to have a structure. Then, the BMC reads a firmware version number of the BMC firmware to be upgraded from the specified non-volatile memory; determines whether the firmware version number is smaller than the minimum upgradable version number; if it is determined that the firmware version number is smaller than the minimum upgradable version number, prohibits the upgrade of the BMC firmware to be upgraded; and if it is determined that the firmware version number is not smaller than the minimum upgradable version number, upgrades the BMC firmware to be upgraded, to achieve the effect of preventing rollback. Subsequently, if the BMC firmware to be upgraded also carries a new version number of the firmware to be revoked, the minimum upgradable version number is updated to the new version number of the firmware to be revoked in a case where it is determined that the new version number of the firmware to be revoked is greater than the minimum upgradable version number.

[0103] In the above example scenario, the minimum upgradable version number is stored in the DDR area, and the data stored in the DDR area is easy to be tampered with, and the security is low.

[0104] To solve the above problems, and in combination with adapting to the BMC processor architecture (including dual processors, respectively, security core and business core), the embodiments of the present application provide a BMC startup, BMC upgrade, firmware compiling method, BMC and computing device. The target firmware stored in the first memory of the BMC includes a security core firmware and a version number file, the version number file at least used to indicate the version number of the firmware not supported by the security core of the BMC, or at least used to indicate the version number of the firmware supported by the security core of the BMC; when the BMC is started, the security core thereof obtains the target firmware from the first memory, and obtains the security core firmware and the version number file therefrom, obtains a first version number set according to the version number file, stores the version number set to the second memory of the BMC, and runs the security core firmware, the second memory not allowing the business core of the BMC to access. By the first version number set stored in the second memory, the firmware for subsequent upgrade of the BMC is checked, so as to avoid the BMC from being upgraded to the firmware that cannot be used, to realize the security protection of the BMC hardware, and to realize the safe upgrade of the BMC.

[0105] For example, as shown in Figure 2 An application scenario diagram of the embodiments of the present application is shown. As shown in Figure 2 The BMC includes a security core and a business core, and the security core and the business core are implemented by different processors. The security core can run program code to realize the functions of firmware safe startup and firmware check, and the business core can run program code to realize the management and monitoring related services of the computing device (such as a server). As shown in Figure 2 The BMC further includes a first memory and a second memory, the first memory can be a non-volatile memory (such as EMMC, flash, etc.), used to store the firmware of the BMC (such as the subsequent target firmware), and the security core and the business core can both access the first memory. The second memory can be SRAM, which does not allow the business core to access, that is, the business core and the program code running thereby cannot access the second memory, so that the secure storage of the data in the second memory can be realized, and the data in the second memory is safe, and the data stored therein is not easy to be tampered with.

[0106] Exemplarily, in the embodiments of the present application, the BMC can include one or more SRAMs, wherein at least one SRAM is not allowed to be accessed by the service core of the BMC, and this kind of SRAM can be referred to as a secure SRAM (i.e., a second memory), the program code running on the secure core is stored in the secure SRAM, and the version number set mentioned later (for example, including but not limited to the first version number set and the second version number set mentioned later) is stored in the secure SRAM. Other SRAMs can be accessed by the service core, for example, the program code running on the service core can be stored in the other SRAMs.

[0107] In the embodiments of the present application, in order to realize the secure upgrade of the BMC, a version number file can be set in the firmware used when the BMC starts, and the version number file is used to indicate the version number of the firmware not supported by the secure core and the service core of the BMC, or to indicate the version number of the firmware supported by the secure core and the service core of the BMC. When starting, the secure core of the BMC stores the version number set generated based on the version number file in the second memory. Then, during the BMC upgrade process, the version number set stored in the second memory can be used to check whether the firmware to be upgraded can be supported (run and used) by the secure core and the service core, and if the check is passed, the upgrade is performed based on the firmware to be upgraded, and if the check is not passed, the upgrade is not performed based on the firmware to be upgraded.

[0108] In some exemplary scenarios, the firmware to be upgraded can be downloaded from the network (hereinafter referred to as downloaded firmware), which can include secure core firmware and service core firmware. In order to realize the security protection of the BMC, for the downloaded firmware that has been determined to be supported (run and used) by the secure core and the service core of the BMC, information indicating the version number of the firmware not supported by the secure core and the service core of the BMC can be added, or information indicating the version number of the firmware supported by the secure core and the service core can be added. The firmware not supported by the secure core and the service core can refer to the firmware that is prohibited to be run and used by the secure core and the service core.

[0109] Based on the description in the above embodiments, the embodiments of the present application provide a BMC firmware (for example, target firmware) compiling method. Next, the firmware compiling process provided by the embodiments of the present application is introduced, and the firmware compiling process can be applied to a first device, which can be implemented by any type of device, apparatus, cluster, etc. with data processing capability.

[0110] As shown in FIG. 3, Figure 3 the process can include the following steps 310-360:

[0111] At step 310, the first device acquires the first secure core firmware and the first version number set, wherein the first version number set is used to indicate version numbers of firmware that is not supported by the secure core of the first BMC, or the first version number set is used to indicate version numbers of firmware that is supported by the secure core of the first BMC.

[0112] For example, when the first device needs to compile the secure core firmware, the first device can acquire the first secure core firmware to be compiled and the first version number set. In some possible examples, the first secure core firmware and the first version number set can be manually input by a compiler. In another possible example, the first device can acquire an acquisition address of the first secure core firmware and the first version number set, and the first device can acquire the first secure core firmware and the first version number set from corresponding locations based on the acquisition address. The first secure core firmware is firmware that can run on the secure core of the first BMC, and can also be used to implement verification of the first service core firmware.

[0113] In some possible examples, the first version number set and the second version number set can be set by a compiler or a specific program according to firmware that is not supported by the secure core and the service core of the first BMC respectively (or firmware that is supported by the secure core and the service core of the first BMC respectively). The setting process of the first version number set is similar to that of the second version number set, and the setting process of the first version number set is described below, and the setting process of the second version number set can be referred to the setting process of the first version number set.

[0114] The compiler or the specific program can set the size of the first version number set according to the number of version numbers of firmware that is not supported by the secure core of the BMC. For example, when setting the first version number set, 1 bit (1 bit) can be used to represent a version number of firmware, or 1 byte or more bytes can be used to represent a version number of firmware. In a possible implementation, to reduce the size of the first version number set, 1 bit can be used to represent a version number of firmware. In another possible implementation, to better and completely represent the version number of firmware, the number of bits occupied by a version number of firmware can be designed according to the version number of firmware that occupies the largest space in actual version numbers.

[0115] In some specific examples, the first version number set can include version numbers of at least one firmware not supported by the secure core of the first BMC, exemplarily as shown in Table 1. In yet some specific examples, the first version number set can include minimum version numbers of firmware supported by the secure core of the first BMC, exemplarily as shown in Table 2. In yet some possible examples, the first version number set can include a type identification of the BMC and version numbers of at least one firmware not supported by the secure core corresponding to different type identifications of the BMC, exemplarily as shown in Table 3. In yet some possible examples, the first version number set can include a type identification of the BMC and minimum version numbers of firmware supported by the secure core corresponding to different type identifications of the BMC, exemplarily as shown in Table 4.

[0116] Table 1, first version number set 1

[0117] Version number V1.1 V1.2 V1.3

[0118] As shown in Table 1, V1.1, V1.2 and V1.3 represent version numbers not supported by the first BMC.

[0119] Table 2, first version number set 2

[0120] Version number V1.1

[0121] As shown in Table 2, V1.1 represents a minimum version number of firmware supported by the first BMC.

[0122] Table 3, first version number set 3

[0123] Type Identification Version number BMC chip 0x1111 V1.1, V1.2, V1.3 BMC chip 0x2222 V1.2, V1.3 Nor Flash1 1 V1.3

[0124] As shown in Table 3, V1.1, V1.2 and V1.3 represent version numbers not supported by the BMC chip when the type identification of the BMC chip is 0x1111, V1.2 and V1.3 represent version numbers not supported by the BMC chip when the type identification of the BMC chip is 0x2222, and V1.3 represents a version number not supported by the BMC chip when the BMC chip is of a non-granular type.

[0125] Table 4, first version number set 4

[0126] Type Identification Version number BMC chip 0x1111 V1.1 BMC chip 0x2222 V1.2 Nor Flash1 1 V1.3

[0127] As shown in Table 3, all version numbers greater than V1.1 represent version numbers supported by the BMC chip when the type identification of the BMC chip is 0x1111, all version numbers greater than V1.2 represent version numbers supported by the BMC chip when the type identification of the BMC chip is 0x2222, and all version numbers greater than V1.3 represent version numbers supported by the BMC chip when the BMC chip is of a non-granular type.

[0128] In some specific examples, the first version number set can include version numbers of at least one firmware supported by the security core of the first BMC. In yet some specific examples, the first version number set can include maximum version numbers of firmware not supported by the security core of the first BMC. In yet some possible examples, the first version number set can include at least one BMC type identifier and version numbers of at least one firmware supported by the security core corresponding to different BMC type identifiers. In yet some possible examples, the first version number set can include at least one BMC type identifier and maximum version numbers of firmware not supported by the security core corresponding to different BMC type identifiers.

[0129] After the first device obtains the first security core firmware and the first version number set, the first device generates a first spliced firmware according to the first security core firmware and the first version number set in step 320.

[0130] In some possible examples, the first security core firmware and the first version number set are both binary data, and accordingly, the first version number set can be spliced in a preset position of the first security core firmware to obtain the first spliced firmware. The preset position can be, for example, a start position of the first security core firmware (i.e., the first security core firmware is at the end position of the first version number set) or a position at the end of the first security core firmware.

[0131] In yet some possible examples, to facilitate the version number set editor to edit the version number set more conveniently, the first version number set is a version number set in text format edited by the editor. Accordingly, step 320 can include steps 321-322 as follows:

[0132] In step 321, the first version number set is compiled into a first version number file in binary format. The first device can pre-store a compiling program for compiling data in text format into data in binary format, and the first device can compile the first version number set in text format into the first version number file in binary format by calling the compiling program. Similar to the function of the first version number set, the first version number file can also be used to indicate version numbers of firmware not supported by the security core, or the first version number file can be used to indicate version numbers of firmware supported by the security core.

[0133] After that, in step 322, the first version number file is spliced at the end of the first security core firmware to obtain the first spliced firmware. In this step, the first security core firmware is in binary format, and accordingly, the first device can splice the first version number file in binary format in a preset position of the first security core firmware, for example, at the end of the first security core firmware, to obtain the first spliced firmware. It can be understood that in yet some examples, the first version number file can also be spliced in other preset positions of the first security core firmware except the end.

[0134] Then, in step 330, the first device acquires the first service core firmware and a second version number set, wherein the second version number set is used to indicate version numbers of firmware that is not supported by the service core of the first BMC, or the second version number set is used to indicate version numbers of firmware that is supported by the service core of the first BMC. The first service core firmware is firmware running on the service core of the first BMC, and is used to provide management and monitoring related services for the computing device to which the first BMC is deployed.

[0135] The process of acquiring the first service core firmware and the second version number set can refer to the process of acquiring the first security core firmware and the first version number set, and will not be described here.

[0136] In step 340, the first device generates a second spliced firmware according to the first service core firmware and the second version number set. The implementation principle of the first device generating the second spliced firmware is similar to that of generating the first spliced firmware, and the implementation process can refer to the implementation process of generating the first spliced firmware described above, and will not be described here. It should be noted that in this process, the first device can compile the second version number set in text form into a second version number file in binary format by calling the compiler. Similar to the role of the second version number set, the second version number file can also be used to indicate version numbers of firmware that is not supported by the service core, or the first version number file is used to indicate version numbers of firmware that is supported by the service core.

[0137] In step 350, the first device determines the header of the target firmware, which includes the position information of the first version number set and the position information of the second version number set. In this step, the first device can acquire the position information of the first version number set (i.e., the first version number file) according to the splicing position of the first version number file when the first spliced firmware is obtained, and can acquire the position information of the second version number set (i.e., the second version number file) according to the splicing position of the second version number file when the second spliced firmware is obtained, and then add the position information of the first version number set and the position information of the second version number set to the header of the target firmware, so that the corresponding information can be acquired based on the position information in the first BMC startup process.

[0138] In some examples, the header can also include position information of the first security core firmware and position information of the first service core firmware.

[0139] In step 360, the first device generates the target firmware according to the header, the first spliced firmware and the second spliced firmware. In this step, the first device can splice the header, the first spliced firmware and the second spliced firmware according to a preset splicing format, and then package the spliced header, the first spliced firmware and the second spliced firmware to obtain the target firmware.

[0140] After obtaining the target firmware, in some possible examples, the first secure core firmware and the first service core firmware can be firmware supported by a secure core and a service core of the first BMC respectively, and accordingly, the first device can send the generated target firmware to the first BMC after obtaining the target firmware, so that the first BMC can store the target firmware in the first memory, so as to obtain and run the target firmware from the first memory after the first BMC is powered on.

[0141] It can be understood that, in yet some possible implementation manners, the first device can not obtain the second version number set, that is, the first service core firmware is included in the second spliced firmware only. Alternatively, in yet some possible implementation manners, the first device can not obtain the first version number set, that is, the first secure core firmware is included in the first spliced firmware only.

[0142] In yet some possible implementation manners, the first device can compile the first version number set and the second version number set into a third version number file after obtaining the first version number set and the second version number set. Then, the first device can splice the first secure core firmware and the third version number file into the first spliced firmware, or the first device can splice the first service core firmware and the third version number file into the second spliced firmware. The head of the target firmware can include only the position information of the first version number set, or can include the position information of the first version number set and the position information of the second version number set.

[0143] The target firmware can be stored in a first memory of the first BMC, and the first BMC is arranged in a second device. It should be noted that the second device can be the same device as the first device, and the target firmware is directly stored in the first memory of the first BMC after the first device generates the target firmware. Alternatively, the first device and the second device can be different devices, and the target firmware is obtained by the second device after the first device generates the target firmware, and then stored in the first memory of the first BMC. Exemplarily, the first memory can be an EMMC or a nor flash.

[0144] After the first BMC is powered on, a starting process is entered, as shown in Figure 4 FIG. 1 shows a flowchart of a BMC starting method.

[0145] The first memory of the first BMC stores the target firmware generated by the compiling method, which exemplarily includes the first secure core firmware and the first version number file (the aforementioned first spliced firmware) and / or the first service core firmware and the second version number file (the aforementioned second spliced firmware), wherein the first version number file is generated based on the aforementioned first version number set and is used to indicate the version number of the firmware not supported by the secure core of the first BMC or the version number of the firmware supported by the secure core of the first BMC; the second version number file is generated based on the aforementioned second version number set and is used to indicate the version number of the firmware not supported by the service core of the first BMC or the version number of the firmware supported by the service core of the first BMC. It can be understood that the target firmware is the firmware supported (i.e., executable) by the secure core and the service core of the first BMC. For reference Figure 4 The process includes the following steps 410-470:

[0146] At step 410, the secure core obtains the target firmware from the first memory.

[0147] Exemplarily, after the first BMC is powered on, the secure core thereof obtains the target firmware from the first memory. The target firmware can include the first secure core firmware in binary format and the first version number file in binary format

[0148] At step 420, the secure core obtains the first secure core firmware and the first version number file according to the target firmware.

[0149] In this step, the secure core parses the target firmware and obtains the first secure core firmware and the first version number file according to the position information of the first secure core firmware and the position information of the first version number file (i.e., the position information of the aforementioned first version number set) stored in the header of the parsed target firmware.

[0150] In some possible examples, the position information corresponding to the first secure core firmware and the first version number file can be represented by the offset information with respect to the aforementioned preset position and the length information of each. For example, for the first version number file, the first version number file can be spliced at the end of the first secure core firmware, and the position information thereof can be represented by the offset information with respect to the preset position (which can include but is not limited to the start position of the first secure core firmware, the end position of the first secure core firmware, etc.) and the length information of the first version number file. For the first secure core firmware, the position information thereof can be represented by the offset information with respect to the preset position (which can include but is not limited to the start position of the first secure core firmware, the start position of the header or the end position of the header, etc.) and the length information of the first secure core firmware.

[0151] At step 430, the secure core obtains the first version number set according to the first version number file.

[0152] In this step, the secure core can compile the first version number set to obtain the decompilation process of the first version number file, and obtain the first version number set based on the first version number file. Specifically, the first version number file in binary format is translated into the first version number set in text format.

[0153] In step 440, the secure core stores the first version number set to the second memory and runs the first secure core firmware.

[0154] In some possible examples, the secure core can store the first version number set to the second memory, which is not accessible to the business core, can prevent the first version number set from being tampered with by the business core or the program code it runs, and can ensure the security of the first version number set; and then run the first secure core firmware. For example, the second memory can be SRAM, which is not accessible to the business core and can be referred to as secure SRAM.

[0155] In yet some possible examples, the secure core can also run the first secure core firmware first, and then store the first version number set to the second memory through the running first secure core firmware.

[0156] In some possible examples, the secure core can obtain the target firmware from the first memory by running the BSBC (Boot Rom Secure Boot Code, secure boot code), parse the secure core firmware from the target firmware to obtain the first version number set, and run the first secure core firmware.

[0157] In step 450, the secure core obtains the first business core firmware and the second version number file according to the target firmware. In this step, the secure core parses the target firmware, and obtains the first business core firmware and the second version number file from the target firmware according to the position information of the first business core firmware and the position information of the second version number file (i.e. the position information of the aforementioned second version number set) stored in the header of the parsed target firmware.

[0158] Then, in step 460, the secure core obtains the second version number set according to the second version number file. In this step, the secure core compiles the second version number file to obtain the decompilation process of the second version number file, and compiles the second version number set based on the second version number file. Specifically, the second version number file in binary format is translated into the second version number set in text format.

[0159] In step 470, the secure core stores the second version number set to the second memory and notifies the business core to run the first business core firmware. In this step, the secure core stores the second version number set to the second memory, and then sends a notification to the business core to notify the business core to run the first business core firmware.

[0160] In some possible implementations, after receiving the notification of the security core, the business core can acquire and parse the target firmware from the first memory, and obtain the first business core firmware from the target firmware based on the position information of the first business core firmware stored in the header of the parsed target firmware, and run the first business core firmware to provide the management and monitoring related service for the corresponding computing device (for example, the second device mentioned above).

[0161] It can be understood that, in yet some possible implementations, the security core can only obtain the first version number set from the target firmware and only store the first version set in the second memory, or the security core can only obtain the second version number set from the target firmware and only store the second version set in the second memory.

[0162] Through the above process, after the first BMC is successfully started, the first BMC can receive the upgrade instruction and enter the upgrade process.

[0163] As shown in Figure 5 , the embodiment of the present application provides a process schematic diagram of BMC firmware upgrade, which can be executed by the first BMC of the second device. Referring to Figure 5 , the process includes the following steps 510-580:

[0164] At step 510, the security core acquires the second security core firmware and the first to-be-verified version number in the upgrade package in response to the upgrade instruction, and the first to-be-verified version number includes the version number of the second security core firmware.

[0165] In some possible examples, the security core of the first BMC acquires the upgrade package from the first memory or other non-volatile memory in response to the upgrade instruction, where the upgrade package can be the upgrade package indicated by the upgrade instruction and downloaded from the network by the business core of the first BMC in response to the upgrade instruction. Then, the security core parses the upgrade package to acquire the second security core firmware and the first to-be-verified version number, which is the version number of the second security core firmware. For example, the upgrade package includes a package header, which can include the position information of the second security core firmware and the first to-be-verified version number in the upgrade package, and the security core can parse the second security core firmware and the first to-be-verified version number from the upgrade package based on the position information of the second security core firmware and the first to-be-verified version number in the parsed package header. In some possible examples, the upgrade package can also be downloaded locally to the BMC, for example, stored in the first memory or other non-volatile memory of the BMC.

[0166] For example, after the service core downloads the upgrade package and stores it in the first memory or other non-volatile memory, the service core can notify the security core that the upgrade package has been downloaded. In response to the upgrade instruction, the security core can obtain the upgrade package from the first memory or other non-volatile memory.

[0167] At step 520, the security core obtains the first version number set from the second memory. At step 530, the security core verifies the second security core firmware based on the first version number set and the first to-be-verified version number.

[0168] After the security core reads the first version number set from the second memory, the security core compares the first version number set with the first to-be-verified version number to verify the second security core firmware. If the verification is passed, the security core performs step 530. If the verification is not passed, the security core determines not to upgrade the second security core firmware.

[0169] In some examples, if the security core of the BMC obtains the second security core firmware and the first to-be-verified version number from the upgrade package through the first security core firmware that the security core runs, and performs the subsequent upgrade process, after the verification of the second security core firmware is not passed and it is determined not to upgrade the second security core firmware, the security core continues to run the first security core firmware.

[0170] In one possible implementation, if the first version number set includes version numbers of at least one firmware that is not supported by the security core of the first BMC, the verification is not passed (i.e., the verification is not successful) when the first to-be-verified version number is the same as any version number in the first version number set, and the verification is passed (i.e., the verification is successful) when the first to-be-verified version number is not the same as all version numbers in the first version number set.

[0171] In one possible implementation, if the first version number set includes the minimum version number of the firmware supported by the security core of the first BMC, the verification is not passed when the first to-be-verified version number is less than the version numbers in the first version number set, and the verification is passed when the first to-be-verified version number is greater than or equal to the version numbers in the first version number set.

[0172] In one possible implementation, if the first version number set includes version numbers of at least one firmware supported by the security core of the first BMC, the verification is passed when the first to-be-verified version number is the same as any version number in the first version number set, and the verification is not passed when the first to-be-verified version number is not the same as all version numbers in the first version number set.

[0173] In a possible implementation, if the first version number set includes the maximum version number of the firmware that is not supported by the security core of the first BMC, when the first to-be-verified version number is less than or equal to the version number in the first version number set, the verification fails, and when the first to-be-verified version number is greater than the version number in the first version number set, the verification passes.

[0174] In a possible implementation, if the first version number set includes the type identifier of at least one BMC and the version number of at least one firmware that is not supported by the security core corresponding to different BMC type identifiers, when the first to-be-verified version number is the same as any one of all the version numbers corresponding to the BMC type identifier in the first version number set, the verification fails, and when the first to-be-verified version number is different from all the version numbers corresponding to the BMC type identifier in the first version number set, the verification passes.

[0175] In a possible implementation, if the first version number set includes the type identifier of at least one BMC and the version number of at least one firmware that is supported by the security core corresponding to different BMC type identifiers, when the first to-be-verified version number is the same as any one of all the version numbers corresponding to the BMC type identifier in the first version number set, the verification passes, and when the first to-be-verified version number is different from all the version numbers corresponding to the BMC type identifier in the first version number set, the verification fails.

[0176] In a possible implementation, if the first version number set includes the type identifier of at least one BMC and the maximum version number of the firmware that is not supported by the security core corresponding to different BMC type identifiers, when the type identifier of the first BMC is the same as the type identifier of one BMC in the first version number set, and the first to-be-verified version number is greater than or equal to the version number corresponding to the BMC type in the first version number set, it is determined that the verification succeeds; and when the type identifier of the first BMC is the same as the type identifier of one BMC in the first version number set, and the first to-be-verified version number is less than the version number corresponding to the BMC type in the first version number set, it is determined that the verification fails.

[0177] In a possible implementation, if the first version number set includes the type identifier of at least one BMC and the maximum version number of the firmware that is not supported by the security core corresponding to different BMC type identifiers, when the type identifier of the first BMC is the same as the type identifier of one BMC in the first version number set, and the first to-be-verified version number is greater than the version number corresponding to the BMC type in the first version number set, the verification passes; and when the type identifier of the first BMC is the same as the type identifier of one BMC in the first version number set, and the first to-be-verified version number is less than or equal to the version number corresponding to the BMC type in the first version number set, the verification fails.

[0178] At step 540, the security core upgrades the first security core firmware to the second security core firmware if the verification is passed. In this step, the security core determines that the second security core firmware passes the verification, i.e., determines that the second security core firmware can be supported (run), and accordingly upgrades the first security core firmware to the second security core firmware. In some examples, the security core can stop running the first security core firmware and then run the second security core firmware at step 540 if the second security core firmware passes the verification by running the first security core firmware.

[0179] Then, at step 550, the security core obtains the second service core firmware and the second to-be-verified version number in the upgrade package, where the second to-be-verified version number includes a version number of the second service core firmware.

[0180] In this step, the security core obtains the second service core firmware and the second to-be-verified version number from the upgrade package by running the second security core firmware. For example, the upgrade package includes a package header, which can include position information of the second service core firmware and the second to-be-verified version number in the upgrade package. The security core can parse the second service core firmware and the second to-be-verified version number from the upgrade package based on the position information of the second service core firmware and the second to-be-verified version number in the package header.

[0181] Then, at step 560, the security core obtains the second version number set from the second memory. At step 570, the security core verifies the second service core firmware based on the second version number set and the second to-be-verified version number.

[0182] After the security core reads the second version number set from the second memory by running the second security core firmware, the security core compares the second version number set with the second to-be-verified version number to verify the second service core firmware, i.e., to verify whether the second service core firmware can be supported (run) by the service core. If the verification is passed, step 570 is performed; if the verification is not passed, it is determined that the second service core firmware is not upgraded.

[0183] In some possible examples, if the second version number set includes a version number of at least one firmware that is not supported by the service core of the first BMC, at step 570, the verification includes: determining that the verification is successful when the second to-be-verified version number is different from all version numbers in the second version number set; and determining that the verification is not successful when the second to-be-verified version number is the same as any version number in the second version number set.

[0184] In yet some possible examples, if the second version number set includes a version number of at least one firmware that is supported by the service core, when the second to-be-verified version number is the same as any version number in the second version number set, it is determined that the verification is successful; and when the second to-be-verified version number is different from all version numbers in the second version number set, it is determined that the verification is not successful.

[0185] In yet some possible examples, if the second version number set includes a minimum version number of the firmware not supported by the business core, the check is determined to be successful when the second to-be-checked version number is greater than or equal to the version number in the second version number set, and the check is determined to be unsuccessful when the second to-be-checked version number is less than the version number in the second version number set.

[0186] In yet some possible examples, if the second version number set includes a maximum version number of the firmware not supported by the business core, the check is determined to be successful when the second to-be-checked version number is greater than the version number in the second version number set, and the check is determined to be unsuccessful when the second to-be-checked version number is less than or equal to the version number in the second version number set.

[0187] In yet some possible examples, if the second version number set includes at least one type identifier of a BMC and at least one version number of the firmware not supported by the business core corresponding to different BMC type identifiers, the check is determined to be successful when the type identifier of the first BMC is the same as the type identifier of one BMC in the second version number set, and the second to-be-checked version number is different from all the version numbers corresponding to the BMC type identifier in the second version number set, and the check is determined to be unsuccessful when the type identifier of the first BMC is the same as the type identifier of one BMC in the second version number set, and the second to-be-checked version number is the same as any one of the version numbers corresponding to the BMC type identifier in the second version number set.

[0188] In yet some possible examples, if the second version number set includes at least one type identifier of a BMC and at least one version number of the firmware supported by the business core corresponding to different BMC type identifiers, the check is determined to be successful when the type identifier of the first BMC is the same as the type identifier of one BMC in the second version number set, and the second to-be-checked version number is the same as any one of the version numbers corresponding to the BMC type identifier in the second version number set, and the check is determined to be unsuccessful when the type identifier of the first BMC is the same as the type identifier of one BMC in the second version number set, and the second to-be-checked version number is different from all the version numbers corresponding to the BMC type identifier in the second version number set.

[0189] In yet some possible examples, if the second version number set includes at least one type identifier of a BMC and a minimum version number of the firmware supported by the business core corresponding to different BMC type identifiers, the check is determined to be successful when the type identifier of the first BMC is the same as the type identifier of one BMC in the second version number set, and the second to-be-checked version number is greater than or equal to the version number corresponding to the BMC type in the second version number set, and the check is determined to be unsuccessful when the type identifier of the first BMC is the same as the type identifier of one BMC in the second version number set, and the second to-be-checked version number is less than the version number corresponding to the BMC type in the second version number set.

[0190] In yet some possible examples, if the second version number set includes the type identifier of at least one BMC and the maximum version number of the firmware that the service core corresponding to the different BMC type identifier does not support, when the type identifier of the first BMC is same as the type identifier of one BMC in the second version number set, and the second to-be-verified version number is greater than the version number corresponding to the BMC type in the second version number set, it is determined that the verification is successful; when the type identifier of the first BMC is same as the type identifier of one BMC in the second version number set, and the second to-be-verified version number is less than or equal to the version number corresponding to the BMC type in the second version number set, it is determined that the verification is unsuccessful.

[0191] In some possible examples, after the second service core firmware is determined not to be upgraded by the second security core firmware through which the security core runs, the second security core firmware can stop running, and the first security core firmware is re-run, and the service core continues to run the first service core firmware, so as to ensure that the management and monitoring related services are provided for the computing device (such as the second device described above).

[0192] In step 580, the security core upgrades the first service core firmware to the second service core firmware if the verification is successful. In this step, if the second service core firmware is determined to be supported (run) by the service core, i.e., the second service core firmware is determined to be verified successfully by the second security core firmware through which the security core runs, the first service core firmware can stop running, and then the second service core firmware obtained from the upgrade package is run, so as to provide the management and monitoring related services for the computing device (such as the second device described above) through the second service core firmware. For example, the service core can load the second service core firmware into the DDR, so as to run the second service core firmware.

[0193] It can be understood that in yet some possible implementations, if only the first version number set exists in the second memory, the security core can only verify the second security core firmware. Alternatively, if only the second version number set exists in the second memory, the security core can only verify the second service core firmware.

[0194] Through the above examples, the first BMC can verify the versions of the second security core firmware and the second service core firmware in the upgrade package based on the first version number set and / or the second version number set stored in the second memory, and the first verification version number and / or the second to-be-verified version number in the upgrade package, upgrade the second security core firmware if it is determined that the security core can support the second security core firmware, and upgrade the second service core firmware if it is determined that the service core can support the second service core firmware, so as to ensure that the upgraded firmware is the firmware that can be supported (run) by the BMC, and to achieve the security protection of the first BMC. Moreover, the second memory is not allowed to be accessed by the service core, and the first version number set and the second version number set stored therein are not easy to be tampered, and the trustworthiness and security are better.

[0195] In some possible examples, the upgrade package can further include a fourth version number file and a fifth version number file. The fourth version number file is used to indicate the version number of the firmware that is not supported by the security core of the first BMC, or the fourth version number set is used to indicate the version number of the firmware that is supported by the security core of the first BMC. The fifth version number file is used to indicate the version number of the firmware that is not supported by the business core of the first BMC, or the fifth version number set is used to indicate the version number of the firmware that is supported by the business core of the first BMC.

[0196] It can be understood that, compared with the first version number file, the fourth version number file is used to indicate more version numbers of the firmware that is not supported by the security core of the first BMC, that is, the version numbers of the firmware that is not supported by the security core of the first BMC indicated by the first version number file and the version numbers of the firmware that is not supported by the security core of the first BMC newly generated between the time when the target firmware is compiled and the time when the upgrade package is compiled. In other words, compared with the first version number file, the fourth version number file is used to indicate more version numbers of the firmware that is supported by the security core of the first BMC, that is, the version numbers of the firmware that is supported by the security core of the first BMC indicated by the first version number file and the version numbers of the firmware that is supported by the security core of the first BMC newly generated between the time when the target firmware is compiled and the time when the upgrade package is compiled.

[0197] Similarly, compared with the second version number file, the fifth version number file is used to indicate more version numbers of the firmware that is not supported by the business core of the first BMC, or in other words, the fifth version number file is used to indicate more version numbers of the firmware that is supported by the security core of the first BMC.

[0198] In the above examples, in order to achieve better security protection of the BMC, the business core can replace the first version number file stored in the second memory with the fourth version number file and replace the second version number file stored in the second memory with the fifth version number file after running the second business core firmware. The version number file is updated to perform version checking on the firmware for subsequent BMC upgrade.

[0199] Considering that the target firmware has the risk of being tampered with, in order to better protect the security of the target firmware and further better protect the security of the first BMC, in some possible examples, as shown in Figure 6 The embodiment of the present application provides another MC firmware compiling method. The BMC firmware compiling process can include the following steps 610-680.

[0200] In step 610, the first security core firmware and the first version number set are obtained.

[0201] In step 620, the first spliced firmware is generated according to the first secure core firmware and the first version number set.

[0202] The implementation principles of steps 610-620 are the same as those of steps 310-320 shown in FIG. 3, and the implementation processes of steps 610-620 can be referred to the implementation processes of steps 310-320, which will not be repeated here. Figure 3 The implementation principles of steps 610-620 are the same as those of steps 310-320 shown in FIG. 3, and the implementation processes of steps 610-620 can be referred to the implementation processes of steps 310-320, which will not be repeated here.

[0203] In step 630, the first private key is used to sign the first spliced firmware to obtain a first signature.

[0204] The first private key and the corresponding public key can be generated by the first device using any public-private key generation algorithm of a public-private key pair, or can be obtained from other devices.

[0205] In some possible examples, the first device can perform a hash operation on the first spliced firmware using a preset hash algorithm (for example, the second hash algorithm mentioned in the embodiments of the present application) to obtain a hash value of the first spliced firmware (i.e., the hash value of the first secure core firmware and the first version number set in the subsequent steps), and then use the private key S CA The first signature is obtained by signing the hash value of the first spliced firmware. In some possible examples, after obtaining the first signature, the first device can splice the first signature at the end (or the head) of the first spliced firmware. In this way, the first device can obtain the position information of the second signature based on the splicing position of the first signature. The process of obtaining the position information of the first signature can be referred to the process of obtaining the position information of the first version number set, which will not be repeated here. The first device can add the position information of the first signature to the head, and accordingly, determine the head of the target firmware including the position information of the first version number set and the position information of the first signature.

[0206] In step 640, the first service core firmware and the second version number set are obtained.

[0207] In step 650, the second spliced firmware is generated according to the first service core firmware and the second version number set.

[0208] The implementation principles of steps 640-650 are the same as those of steps 330-340, and the implementation processes of steps 640-650 can be referred to the implementation processes of steps 330-340, which will not be repeated here.

[0209] In step 660, the second private key is used to sign the second spliced firmware to obtain a second signature.

[0210] The second private key and its corresponding public key can be generated by the first device using any public-private key generation algorithm capable of generating public-private key pairs. The second private key can be the same as or different from the aforementioned first private key.

[0211] In some possible examples, the first device can use a preset hash algorithm (such as the third hash algorithm mentioned in the embodiments of this application) to perform a hash operation on the second concatenated firmware to obtain the hash value of the second concatenated firmware (i.e., the hash value of the subsequent first service core firmware and the second version number set), and then use the private key S of the Certificate Authority (CA) CA The hash value of the second spliced ​​firmware is signed to obtain the second signature.

[0212] In some possible examples, after obtaining the second signature, the first device can append the second signature to the end (or beginning) of the second firmware. In this way, the first device can obtain the location information of the second signature based on its appended position. The process of obtaining the location information of the second signature can be referred to the aforementioned process of obtaining the location information of the first version number set, and will not be repeated here. Subsequently, the first device can add the location information of the second signature to the header, thereby determining the header of the target firmware that includes the location information of the second version number set and the location information of the second signature.

[0213] In step 670, the header of the target firmware is determined. The header includes the location information of the first version number set and the location information of the second version number set. Similar to step 350, it will not be described again here.

[0214] In step 680, the target firmware is generated based on the header, the first spliced ​​firmware, the first signature, the second spliced ​​firmware, and the second signature. For example... Figure 7 The diagram illustrates a splicing method, showing a splicing result obtained by splicing the header, first splicing firmware, first signature, second splicing firmware, and second signature. It is understood that the first device can splice the header, first splicing firmware, first signature, second splicing firmware, and second signature in any specified splicing order. This embodiment does not limit the splicing order of the header, first splicing firmware, first signature, second splicing firmware, and second signature. After splicing the header, first splicing firmware, first signature, second splicing firmware, and second signature, they are packaged to generate the target firmware.

[0215] Understandably, in some possible implementations, the first device may not obtain the second version number set; that is, the second splicing firmware only includes the first service core firmware. Alternatively, in some possible implementations, the first device may not obtain the first version number set; that is, the first splicing firmware only includes the first security core firmware.

[0216] In yet some possible implementation manners, after obtaining the first version number set and the second version number set, the first device can compile the first version number set and the second version number set into a third version number file. The first device can splice the first secure core firmware and the third version number file into the first spliced firmware, or the first device can splice the first service core firmware and the third version number file into the second spliced firmware. Then, the header of the target firmware can only include the position information of the first version number set, or can also include the position information of the first version number set and the position information of the second version number set.

[0217] Based on the above embodiments, in order to better implement the secure startup of the firmware of the first BMC, the target firmware can further include a first signature, which is obtained by signing the first secure core firmware and the first version number file. Before starting the first secure core firmware, the integrity and trustworthiness of the first secure core firmware and the first version number file need to be verified. Correspondingly, as shown in Figure 8 The BMC startup method can include the following steps 810-860.

[0218] In step 810, the target firmware is obtained. The implementation principle of step 810 is similar to that of step 410 in the method for obtaining the target firmware, and the implementation process can refer to that of step 810, which will not be repeated here. Figure 4

[0219] In step 820, the first secure core firmware, the first version number file and the first signature are obtained according to the target firmware. In this step, the principle of obtaining the first secure core firmware, the first version number file and the first signature according to the target firmware by the secure core of the first BMC is similar to that of obtaining the first secure core firmware and the first version number file according to the target firmware, and the implementation process can refer to the implementation process of obtaining the first secure core firmware and the first version number file according to the target firmware.

[0220] The first signature is obtained by signing the first secure core firmware and the first version number file, for example, by signing the hash values of the first secure core firmware and the first version number file.

[0221] In step 830, the public key information is obtained from the one-time programmable (OTP) memory. In step 840, the first secure core firmware and the first version number file are verified according to the public key information and the first signature.

[0222] ​The data stored in the one-time programmable OTP memory cannot be modified or deleted, and the stored data is highly reliable. The public key information can be burned into the OTP memory of the first BMC when the first BMC is manufactured. In an example, the public key information stored in the one-time programmable OTP memory can be the public key G CA of a certificate authority (CA). CA The hash value H[G CA ]1 obtained after the hash operation of the first hash algorithm.

[0223] In the above example, in the case where the public key information is the hash value of the public key G CA , the target firmware can include a certificate, wherein the certificate includes the aforementioned public key G CA , the first public key G1, and the signature of the first public key G1. The first signature is obtained by signing the hash value of the first secure core firmware and the first version number file using the private key S1 (e.g., the first private key mentioned later) of the first device during the compilation of the target firmware. The first public key is the public key corresponding to the private key S1. The signature of the first public key G1 is obtained by signing the hash value H[G1]1 of the first public key G1 using the private key S CA of the CA. The hash value H[G1]1 of the first public key G1 is obtained by performing a hash operation on the first public key G1 using a second hash algorithm.

[0224] The private key S1 and the corresponding first public key G1 are generated using any public-private key pair generation algorithm in the related art. The first hash algorithm and the second hash algorithm can be the same or different.

[0225] In some possible examples, the process of verifying the first secure core firmware and the first version number file in step 840 can include: a verification process of the public key G CA in the certificate using the public key information (i.e., the hash value H[G CA of the public key G CA in the certificate is passed, a verification process of the first public key G1 using the public key G CA in the certificate, and a process of verifying the first secure core firmware and the first version number file using the first public key G1 and the first signature after the verification of the first public key G1 is passed.

[0226] The verification process of the public key G CA in the certificate using the public key information (i.e., the hash value H[G CA of the public key G CA in the certificate can include: performing a hash operation on the public key G CAThe hash value H[G CA ]2; Compare public key G CA The hash value H[G CA ]2 and hash value H[G CA 1. If public key G CA The hash value H[G CA ]2 and hash value H[G CA If 1 is the same, then the public key G in the certificate is determined. CA Verification passed. Next, the public key G from the certificate will be used. CA The verification process for the first public key G1. If public key G... CA The hash value H[G CA ]2 and hash value H[G CA If 1 is different, then the public key G in the certificate is determined. CA If the verification fails, the verification process will stop. A notification message can then be output to indicate that the target firmware has been tampered with.

[0227] Among them, the public key G in the certificate is used CA The verification process for the first public key G1 may include: using the public key G CA The signature of the first public key G1 is decrypted to obtain its hash value H[G1]1. A second hash algorithm is then used to hash the first public key G1 in the certificate, yielding its hash value H[G1]2. H[G1]2 and H[G1]1 are compared. If they match, the verification of the first public key G1 in the certificate is successful. The process then proceeds to verify the first secure firmware and the first version number file using the first public key G1 and the first signature. If they differ, the verification of the first public key G1 in the certificate fails, and the verification process stops. A notification message can then be output to indicate that the target firmware has been tampered with.

[0228] Specifically, the process of checking the first secure kernel firmware and the first version number file by using the first public key G1 and the first signature can include: decrypting the first signature by using the first public key G1 to obtain a hash value 1 of the first secure kernel firmware and the first version number file; performing a hash operation on the first secure kernel firmware and the first version number file by using a third Hash algorithm to obtain a hash value 2 of the first secure kernel firmware and the first version number file; comparing the hash value 1 and the hash value 2 of the first secure kernel firmware and the first version number file, and if it is determined that the hash value 1 and the hash value 2 of the first secure kernel firmware and the first version number file are the same, it is determined that the first secure kernel firmware and the first version number file pass the check, and then the step 1150 can be continued to be executed. If it is determined that the hash value 1 and the hash value 2 of the first secure kernel firmware and the first version number file are different, it is determined that the first secure kernel firmware cannot be started. Subsequently, prompt information can be output, and the prompt information is used to prompt that the target firmware is tampered.

[0229] The third Hash algorithm is the same as the Hash algorithm used in the hash operation on the first secure kernel firmware and the first version number file in the compiling process. The third Hash algorithm can be the same as the first Hash algorithm and the second Hash algorithm, or can be different.

[0230] In an example, in the case that the public key information is the public key G CA , the process of checking the first secure kernel firmware and the first version number file in the step 840 can include: checking the first public key G1 by using the public key G CA , and checking the first secure kernel firmware and the first version number file by using the first public key G1 and the first signature. The process of checking the first public key G1 by using the public key G CA , and the process of checking the first secure kernel firmware and the first version number file by using the first public key G1 and the first signature can refer to the process of checking the first public key G1 by using the public key G CA , and the process of checking the first secure kernel firmware and the first version number file by using the first public key G1 and the first signature, which will not be described herein.

[0231] In some possible examples, the public key information in the OTP memory can include the public key corresponding to the first signature, that is, the first public key G1 described above, at this time, the first secure kernel firmware and the first version number file can be checked by using the first public key G1 included in the public key information and the first signature, and the process can refer to the process of checking the first secure kernel firmware and the first version number file by using the first public key G1 and the first signature, which will not be described herein.

[0232] In some possible examples, the public key information in the OTP memory can include a hash value of the public key corresponding to the first signature, i.e., the hash value of the first public key G1 mentioned above, and the certificate in the target firmware can include the first public key G1. Accordingly, the process of verifying the first secure core firmware and the first version number file by using the public key information and the first signature can include: performing a hash operation on the first public key G1 in the certificate by using a second Hash algorithm to obtain a hash value H[G1]2 of the first public key G1, and comparing the hash value H[G1]2 of the first public key G1 with the hash value of the first public key G1 stored in the OTP. If the hash value H[G1]2 of the first public key G1 is the same as the hash value of the first public key G1 stored in the OTP, the first secure core firmware and the second version number file are verified by using the first public key G1 in the certificate and the second signature.

[0233] Then, in step 850, if the first secure core firmware and the first version number file are verified according to the public key information and the first signature, a first version number set is obtained according to the first version number file. The implementation principle of step 850 is similar to that of step 430 shown in FIG. 4B, and the implementation process can be referred to the implementation process of step 430, which is not described herein again. Figure 4 The implementation principle of step 860 is similar to that of step 440 shown in FIG. 4B, and the implementation process can be referred to the implementation process of step 440, which is not described herein again.

[0234] In step 860, the first version number set is stored in the second memory, and the first secure core firmware is run, and the second memory is not allowed to be accessed by the service core. The implementation principle of step 860 is similar to that of step 440 shown in FIG. 4B, and the implementation process can be referred to the implementation process of step 440, which is not described herein again. Figure 4 The implementation principle of step 860 is similar to that of step 440 shown in FIG. 4B, and the implementation process can be referred to the implementation process of step 440, which is not described herein again.

[0235] In the above examples, the first secure core firmware and the first version number file are verified by using the public key information and the first signature to determine whether the first secure core firmware and the first version number file are tampered with. If it is determined that the first secure core firmware and the first version number file are not tampered with, i.e., the first secure core firmware and the first version number file are verified, a subsequent starting process is performed to further protect the BMC.

[0236] In some possible examples, in order to better implement the secure starting of the firmware of the first BMC, the target firmware can further include a second signature obtained by signing the first service core firmware and the second version number file. Before starting the first service core firmware, the integrity and the trustworthiness of the first service core firmware and the second version number file need to be verified. Accordingly, as shown in FIG. 8B, after the first version number set is stored in the second memory and the first secure core firmware is run in step 860, the BMC starting method can further include steps 870-8100 as follows. Figure 8

[0237] ​At step 870, the first service core firmware, the second version number file and the second signature are obtained according to the target firmware. In this step, the security core of the first BMC obtains the first service core firmware, the second version number file and the second signature according to the target firmware through the running first security core firmware, and the principle of obtaining the first service core firmware, the second version number file and the second signature according to the target firmware is similar to that of obtaining the first security core firmware, the first version number file and the first signature according to the target firmware. The implementation process can refer to the foregoing implementation process of obtaining the first security core firmware, the first version number file and the first signature according to the target firmware.

[0238] The second signature is obtained by signing the first service core firmware and the second version number file, for example, is obtained by signing the hash values of the first service core firmware and the second version number file.

[0239] At step 880, the first service core firmware and the second version number file are verified according to the foregoing public key information and the second signature.

[0240] For example, the public key information can include the public key G CA of the CA, can include the public key G CA , and can include the hash value H[G CA ]1 of the public key G CA of the CA obtained through the first Hash algorithm, and can include the public key (for example, referred to as the second public key G2) corresponding to the second signature or the hash value of the second public key G2.

[0241] When the public key information is the hash value H[G CA ]1 of the public key G CA of the CA, the foregoing certificate can further include the second public key G2 and the signature of the second public key G2, wherein the second public key is the public key corresponding to the private key S2 (i.e., the foregoing second private key), and the signature of the second public key G2 is obtained by the CA using the private key S CA to sign the hash value H[G2]1 of the second public key G2, and the hash value H[G2]1 of the second public key G2 is obtained by the CA using the fourth Hash algorithm to hash the second public key G2. The second signature is obtained by the first device using the private key S2 to sign the hash values of the first service core firmware and the second version number file in the process of compiling the target firmware. The fourth Hash algorithm can be the same as or different from the foregoing first Hash algorithm, second Hash algorithm and third Hash algorithm.

[0242] When the public key information includes the public key G CA of the CA or the public key G CA , the hash value H[G CAIn the case of the first business core firmware and the second version number file being verified according to the public key information and the second signature, the process can refer to the process of the first secure core firmware and the first version number file being verified according to the public key information and the first signature, which will not be repeated here.

[0243] In the case of the public key information including the second public key G2 or including the hash value of the second public key G2, the process of the first business core firmware and the second version number file being verified according to the public key information and the second signature can refer to the process of the first secure core firmware and the first version number file being verified according to the public key information and the first signature, which will not be repeated here.

[0244] In some possible examples, in the case of the public key information in the OTP memory including the second public key G2 corresponding to the second signature, the second public key G2 included in the public key information can be directly used to verify the first business core firmware and the second version number file according to the second signature, where the process can refer to the process of the first secure core firmware and the first version number file being verified according to the first public key G1 and the first signature, which will not be repeated here. In some possible examples, in the case of the public key information in the OTP memory including the hash value of the second public key G2, in step 880, the hash value of the second public key G2 included in the public key information can be used to verify the second public key G2 in the target firmware, and if the verification is passed, the second public key G2 in the target firmware is used to verify the first business core firmware and the second version number file according to the second signature.

[0245] In some possible examples, the second public key G2 corresponding to the second signature can also be stored in the first secure core firmware. After it is determined that the first secure core firmware is verified according to the public key information and the first signature, it can be considered that the second public key G2 corresponding to the second signature is verified. At this time, the secure core can parse the second public key G2 from the first secure core firmware, and then verify the first business core firmware and the second version number file based on the parsed second public key G2 and the second signature.

[0246] In step 890, when the verification is passed, the second version number set is obtained according to the second version number file. The implementation principle of step 890 is similar to that of step 460, and the implementation process of step 890 can refer to that of step 460, which will not be repeated here.

[0247] In step 8100, the second version number set is stored in the second memory. The implementation principle of step 8100 is similar to that of step 470, and the implementation process of step 8100 can refer to that of step 470, which will not be repeated here.

[0248] Understandably, in some other possible implementations, the security kernel may obtain only the first version number set from the target firmware and store only the first version number set in the second memory, or the security kernel may obtain only the second version number set from the target firmware and store only the second version number set in the second memory.

[0249] In the above example, the integrity and trustworthiness of the first business core firmware and the second version number file are verified. After the verification of the first business core firmware and the second version number file is passed, the subsequent process is carried out to further realize the secure boot of the first BMC and realize the security protection of the first BMC.

[0250] Referring to the above embodiments, in order to better protect the BMC, the upgrade package also includes a third signature obtained by signing the second security core firmware and the first version number to be verified. Accordingly, this application embodiment also provides a BMC upgrade method. Step 510 may specifically include: the first BMC security core responds to the upgrade command, obtains the second security core firmware, the first version number to be verified, and the third signature from the upgrade package; obtains public key information from a one-time programmable OTP memory; and verifies the second security core firmware and the first version number to be verified using the public key information and the third signature; if the verification passes, it is determined that the second security core firmware and the first version number to be verified have not been tampered with, and then steps 520-530 are executed. The implementation principle of using public key information and the third signature to verify the second security core firmware and the first version number to be verified is similar to the aforementioned implementation principle of using public key information and the first signature to verify the first security core firmware and the first version number file. Its implementation process can be referred to the aforementioned implementation process of using public key information and the first signature to verify the first security core firmware and the first version number file, which will not be repeated here.

[0251] If the public key information and the third signature are used to verify the second security core firmware and the first version number to be verified, and the verification fails, it can be determined that the second security core firmware and the first version number to be verified have been tampered with. In this case, the upgrade process is stopped, the security core of the first BMC continues to run the first security core firmware, and the service core continues to run the first service core firmware.

[0252] In the example above, signature verification of the second secure kernel firmware and the first version number to be verified can prevent upgrading to the tampered second secure kernel firmware, thus further achieving better security protection for the BMC.

[0253] In some possible examples, in order to better achieve the security protection of the BMC, the upgrade package further includes a fourth signature obtained by signing the second service core firmware and the second version number to be verified, and correspondingly, the step 540 can specifically include: the security core of the first BMC acquires the second service core firmware, the second version number to be verified and the fourth signature in the upgrade package by running the second security core firmware, and verifies the second service core firmware and the second version number to be verified by using the public key information and the fourth signature; if the verification is passed, it is determined that the second service core firmware and the second version number to be verified are not tampered, and steps 550-560 are performed. The implementation principle of verifying the second service core firmware and the second version number to be verified by using the public key information and the fourth signature is similar to the implementation principle of verifying the first security core firmware and the first version number file by using the public key information and the first signature. For the implementation process, refer to the implementation process of verifying the first security core firmware and the first version number file by using the public key information and the first signature, which will not be described herein.

[0254] For example, if the verification of the second service core firmware and the second version number to be verified by using the public key information and the fourth signature is not passed, it is determined that the second service core firmware and the second version number to be verified are tampered, and the upgrade process is stopped, and the security core of the first BMC continues to run the first security core firmware, and the service core continues to run the first service core firmware.

[0255] In the above examples, the signature verification of the second service core firmware and the second version number to be verified can avoid upgrading to the tampered second service core firmware, and further better achieve the security protection of the BMC.

[0256] Based on the method in the above embodiments, an embodiment of the present application provides a substrate management controller (BMC) starting device. Please refer to Figure 9 , Figure 9 is a structural schematic diagram of a BMC starting device 900 provided by an embodiment of the present application. The device 900 can be deployed in a first BMC, the first BMC including a security core, a service core and a first memory, the first memory storing a target firmware, the target firmware including a first security core firmware and a first version number file, the first version number file being used to indicate a version number of a firmware not supported by the security core, or the first version number file being used to indicate a version number of a firmware supported by the security core, such as Figure 9As shown, the apparatus 900 can include a first obtaining module 910 configured to obtain the target firmware, a first obtaining module 920 configured to obtain the first secure kernel firmware and the first version number file according to the target firmware, a second obtaining module 930 configured to obtain a first version number set according to the first version number file, and a first storage and running module 940 configured to store the first version number set to a second memory and run the first secure kernel firmware, the second memory not allowing the business kernel to access.

[0257] In some possible examples, the target firmware further includes a first signature, and the first obtaining module 920 is specifically configured to obtain the first secure kernel firmware, the first version number file and the first signature according to the target firmware.

[0258] The second obtaining module 930 is specifically configured to obtain public key information from a one-time programmable (OTP) memory before obtaining the first version number set according to the version number file.

[0259] The first secure kernel firmware and the first version number file are verified according to the public key information and the first signature.

[0260] When the verification passes, the first version number set is obtained according to the first version number file.

[0261] In some possible examples, the target firmware further includes a first business kernel firmware and a second version number file, the second version number file being used to indicate a version number of a firmware not supported by the business kernel, or the second version number file being used to indicate a version number of a firmware supported by the business kernel, and the apparatus further includes:

[0262] A third obtaining module (not shown in the figure) is configured to obtain the first business kernel firmware and the second version number file according to the target firmware.

[0263] A fourth obtaining module (not shown in the figure) is configured to obtain a second version number set according to the second version number file.

[0264] A second storage and running module (not shown in the figure) is configured to store the second version number set to the second memory and run the first business kernel firmware.

[0265] In some possible examples, the target firmware further includes a second signature, and the third obtaining module is specifically configured to obtain the first business kernel firmware, the second version number file and the second signature according to the target firmware.

[0266] The fourth obtaining module is specifically configured to obtain public key information from a one-time programmable (OTP) memory.

[0267] verify the first service core firmware and the second version number file according to the public key information and the second signature;

[0268] When the verification passes, obtain a second version number set according to the second version number file.

[0269] In some possible examples, the target firmware further includes a second signature, and the third obtaining module is specifically configured to obtain the first service core firmware, the second version number file and the second signature according to the target firmware.

[0270] The fourth obtaining module is specifically configured to obtain the public key information from the first secure core firmware.

[0271] verify the first service core firmware and the second version number file according to the public key information and the second signature;

[0272] When the verification passes, obtain a second version number set according to the second version number file.

[0273] Based on the method in the above embodiments, an embodiment of the present application provides a BMC firmware upgrading device, please refer to Figure 10 , Figure 10 is a structural schematic diagram of a BMC firmware upgrading device 1000 provided by an embodiment of the present application. The BMC upgrading device is deployed in a first BMC, the first BMC includes a secure core, a service core and a second memory, the secure core runs a first secure core firmware, the second memory stores a first version number set, the first version number set is used to indicate a version number of a firmware that is not supported by the secure core, or the first version number set is used to indicate a version number of a firmware that is supported by the secure core, and the second memory does not allow the service core to access. The device 1000 includes: a second obtaining module 1010, configured to obtain a second secure core firmware and a first to-be-verified version number in an upgrading package in response to an upgrading instruction, the first to-be-verified version number being a version number of the second secure core firmware; a third obtaining module 1020, configured to obtain the first version number set from the second memory; a first verification module 1030, configured to verify the second secure core firmware based on the first version number set and the first to-be-verified version number; and a first upgrading module 1040, configured to upgrade the first secure core firmware to the second secure core firmware if the verification is successful.

[0274] In some possible examples, the first verification module 1030 is specifically configured to determine that the verification is successful when the first to-be-verified version number is different from all version numbers in the first version number set, and the first version number set includes version numbers of at least one firmware that is not supported by the secure core; or

[0275] determining that the check is successful when the first version number to be checked is equal to any version number in the first version number set, wherein the first version number set comprises version numbers of at least one firmware supported by the secure core; or

[0276] determining that the check is successful when the first version number to be checked is greater than or equal to a version number in the first version number set, wherein the first version number set comprises a minimum version number of firmware not supported by the secure core; or

[0277] determining that the check is successful when the first version number to be checked is greater than a version number in the first version number set, wherein the first version number set comprises a maximum version number of firmware not supported by the secure core.

[0278] In some possible examples, the business core runs a first business core firmware, and the second memory further stores a second version number set, the second version number set being used to indicate version numbers of firmware not supported by the business core, or the second version number set being used to indicate version numbers of firmware supported by the business core, and the apparatus further comprises:

[0279] a fourth obtaining module (not shown in the figure) configured to obtain a second business core firmware and a second version number to be checked in the upgrade package, the second version number to be checked being a version number of the second business core firmware;

[0280] a fifth obtaining module (not shown in the figure) configured to obtain the second version number set from the second memory;

[0281] a second checking module (not shown in the figure) configured to check the second business core firmware based on the second version number set and the second version number to be checked;

[0282] a second upgrading module (not shown in the figure) configured to upgrade the first business core firmware to the second business core firmware if the check is successful.

[0283] In some possible examples, the second checking module is specifically configured to determine that the check is successful when the second version number to be checked is not equal to any version number in the second version number set, wherein the second version number set comprises version numbers of at least one firmware not supported by the business core; or

[0284] determining that the check is successful when the second version number to be checked is equal to any version number in the second version number set, wherein the second version number set comprises version numbers of at least one firmware supported by the business core; or

[0285] determining that the check succeeds when the second version number to be checked is greater than or equal to a version number in the second version number set, wherein the second version number set comprises a minimum version number of firmware supported by the service core; or

[0286] determining that the check succeeds when the second version number to be checked is greater than a version number in the second version number set, wherein the second version number set comprises a maximum version number of firmware not supported by the service core.

[0287] Based on the method in the above embodiments, an embodiment of the present application provides a BMC firmware compiling device, please refer to Figure 11 , Figure 11 is a structural diagram of a BMC firmware compiling device 1100 provided by an embodiment of the present application. The device 1100 comprises a sixth acquisition module 1110 configured to acquire a first secure core firmware and a first version number set, wherein the first version number set is used to indicate a version number of firmware not supported by a secure core of a first BMC, or the first version number set is used to indicate a version number of firmware supported by the secure core; a first generation module 1120 configured to generate a first spliced firmware according to the first secure core firmware and the first version number set; a determination module 1130 configured to determine a header of a target firmware, wherein the header comprises position information of the first version number set; and a second generation module 1140 configured to generate the target firmware according to the header and the first spliced firmware.

[0288] In some possible examples, the device further comprises:

[0289] a first signature module (not shown in the figure) configured to, after the first spliced firmware is generated according to the first secure core firmware and the first version number set, use a first private key to sign the first spliced firmware to obtain a first signature;

[0290] The second generation module 1140 is specifically configured to generate the target firmware according to the header, the first spliced firmware and the first signature.

[0291] In some possible examples, the device further comprises:

[0292] a seventh acquisition module (not shown in the figure) configured to, before the target firmware is generated according to the header and the first spliced firmware, acquire a first service core firmware and a second version number set, wherein the second version number set is used to indicate a version number of firmware not supported by a service core of the first BMC, or the first version number set is used to indicate a version number of firmware supported by the service core;

[0293] a third generating module (not shown in the figure) configured to generate a second spliced firmware according to the first service core firmware and the second version number set;

[0294] The determining module 1130 is specifically configured to determine a header of the target firmware, and the header includes position information of the first version number set and position information of the second version number set.

[0295] The second generating module 1140 is specifically configured to generate the target firmware according to the header, the first spliced firmware, the second spliced firmware, the first signature, and the second signature.

[0296] In some possible examples, the apparatus further includes:

[0297] a second signing module (not shown in the figure) configured to, after the second spliced firmware is generated according to the first service core firmware and the second version number set, sign the second spliced firmware using a second private key to obtain a second signature.

[0298] The second generating module 1140 is specifically configured to generate the target firmware according to the header, the first spliced firmware, the second spliced firmware, the first signature, and the second signature.

[0299] In some possible examples, the first generating module 1120 is specifically configured to compile the first version number set into a first version number file, and the first version number file is in a binary format; and splice the first version number file at the end of the first secure core firmware to obtain the first spliced firmware.

[0300] In some possible examples, the third generating module is specifically configured to compile the second version number set into a second version number file, and the second version number file is in a binary format; and splice the second version number file at the end of the first service core firmware to obtain the second spliced firmware.

[0301] It should be understood that the apparatus is used to execute the method in the above-described embodiments, and the corresponding program modules in the apparatus have similar implementation principles and technical effects to those described in the above method, and the working process of the apparatus can refer to the corresponding process in the above method, which will not be described here.

[0302] Based on the method in the above-described embodiments, the embodiments of the present application provide a BMC. The BMC is used to execute the BMC starting or BMC firmware upgrading method in the above-described embodiments.

[0303] Based on the method in the above embodiment, the embodiment of the application provides a computing device. The computing device comprises a central processor and a third memory, and the central processor is used to execute a computer program stored on the third memory to execute the BMC firmware compiling method in the above embodiment.

[0304] Based on the method in the above embodiment, the embodiment of the application provides a computing device. The computing device comprises a central processor and a BMC, and the BMC is used to execute the BMC starting or BMC firmware upgrading method in the above embodiment.

[0305] Based on the method in the above embodiment, the embodiment of the application provides a computer readable storage medium, and the computer readable storage medium stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0306] Based on the method in the above embodiment, the embodiment of the application provides a computer program product. When the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0307] Based on the method in the above embodiment, the embodiment of the application further provides a chip. The chip comprises at least two processors, a first memory, a second memory and an interface circuit.

[0308] The processor can be an integrated circuit chip with a processing capability of signals. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. Illustratively, the processor can comprise a security core processor and a business core processor.

[0309] The interface circuit can be used for sending or receiving data, instructions or information. The processor can process the data, instructions or other information received by the interface circuit, and can send the processed information out through the interface circuit 1202.

[0310] Optionally, the interface circuit can be used for outputting the execution result of the processor.

[0311] It should be noted that the functions of the processor, the memory and the interface circuit correspondingly can be realized by hardware design, software design or a combination of hardware and software, which is not limited here.

[0312] It should be understood that each step of the above method embodiment can be completed by a logic circuit in the form of hardware or an instruction in the form of software in the processor.

[0313] It can be understood that the size of the serial number of each step in the above-mentioned embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, each step in the above-mentioned embodiments can be selectively executed, partially executed, or fully executed according to actual conditions, which is not limited here.

[0314] In the above-mentioned embodiments, all or part can be realized by software, hardware, firmware or any combination thereof. When realized by software, all or part can be realized in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in or transmitted by a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through a wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, data center, etc. integrated with one or more available media sets. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)) and the like.

[0315] It can be understood that the various numerical numbers involved in the embodiments of the present application are only distinguished for convenience of description, and are not used to limit the scope of the embodiments of the present application.

Claims

1. A method for starting a Baseboard Management Controller (BMC), characterized in that, A security core is applied to a first Business Controller (BMC), the first BMC including the security core, a service core, and a first memory. The first memory stores target firmware, the target firmware including first security core firmware and a first version number file. The first version number file is used to indicate the version number of firmware that the security core does not support, or the first version number file is used to indicate the version number of firmware that the security core supports. The target firmware also includes a first service core firmware and a second version number file. The second version number file is used to indicate the version number of firmware that the service core does not support, or the second version number file is used to indicate the version number of firmware that the service core supports. The method includes: After the BMC is powered on, the target firmware is acquired; The first security core firmware and the first version number file are obtained based on the target firmware; the first service core firmware and the second version number file are obtained based on the target firmware; Retrieve public key information from a one-time programmable OTP memory; Verify the first security kernel firmware and the first version number file based on the public key information; A first version number set is obtained based on the first version number file; a second version number set is obtained based on the second version number file; wherein the first version number set includes the type identifier of the BMC, and indicates the firmware version number that the corresponding security kernel supports or does not support based on different type identifiers; The first version number set and the second version number set are stored in the second memory, and the first security core firmware is run. The second memory does not allow the service core to access it. After the first security core firmware verification is passed, the security core notifies the service core to run the first service core firmware.

2. The method as described in claim 1, characterized in that, The target firmware further includes a first signature, and the step of obtaining the first security core firmware and the first version number file based on the target firmware specifically includes: The first security kernel firmware, the first version number file, and the first signature are obtained based on the target firmware. Before obtaining the first version number set based on the version number file, the method further includes: The first secure kernel firmware and the first version number file are verified based on the public key information and the first signature.

3. The method as described in claim 1, characterized in that, The target firmware further includes a second signature, and the process of obtaining the first service core firmware and the second version number file based on the target firmware specifically includes: The first service core firmware, the second version number file, and the second signature are obtained based on the target firmware. Before obtaining the second version number set based on the version number file, the method further includes: Retrieve public key information from a one-time programmable OTP memory; Verify the first service core firmware and the second version number file based on the public key information and the second signature; When the verification passes, the second version number set is obtained based on the second version number file.

4. The method as described in claim 1, characterized in that, The target firmware further includes a second signature, and the process of obtaining the first service core firmware and the second version number file based on the target firmware specifically includes: The first service core firmware, the second version number file, and the second signature are obtained based on the target firmware. Before obtaining the second version number set based on the version number file, the method further includes: Obtain public key information from the first security kernel firmware; Verify the first service core firmware and the second version number file based on the public key information and the second signature; When the verification passes, the second version number set is obtained based on the second version number file.

5. The method according to any one of claims 1-4, characterized in that, Also includes: In response to the upgrade command, the second security core firmware and the first version number to be verified are obtained from the upgrade package, wherein the first version number to be verified is the version number of the second security core firmware; Obtain the first version number set from the second memory; The second security kernel firmware is verified based on the first version number set and the first version number to be verified. If the verification is successful, the first security kernel firmware will be upgraded to the second security kernel firmware.

6. The method as described in claim 5, characterized in that, The verification of the second security kernel firmware based on the first version number set and the first version number to be verified specifically includes: The verification is successful when the first version number to be verified is different from all version numbers in the first version number set, wherein the first version number set includes version numbers of at least one firmware that is not supported by the security kernel; or... When the first version number to be verified is the same as any version number in the first version number set, the verification is determined to be successful, wherein the first version number set includes the version number of at least one firmware supported by the security kernel.

7. The method as described in claim 5, characterized in that, The verification of the second security kernel firmware based on the first version number set and the first version number to be verified specifically includes: The verification is successful when the first version number to be verified is greater than or equal to the version number in the first set of version numbers, wherein the first set of version numbers includes the minimum version number of the firmware supported by the security kernel; or... When the first version number to be verified is greater than the version number in the first set of version numbers, the verification is determined to be successful. The first set of version numbers includes the maximum version number of firmware that is not supported by the security kernel.

8. The method as described in claim 5, characterized in that, The verification of the second security kernel firmware based on the first version number set and the first version number to be verified specifically includes: When the type identifier of the first BMC is the same as the type identifier of a BMC in the first version number set, and the first version number to be verified is different from all version numbers corresponding to that BMC type identifier in the first version number set, the verification is determined to be successful. The first version number set includes at least one BMC type identifier and version numbers of at least one firmware that is not supported by the security kernel corresponding to different BMC type identifiers; or, When the type identifier of the first BMC is the same as the type identifier of a BMC in the first version number set, and the first version number to be verified is the same as any version number corresponding to the type identifier of the BMC in the first version number set, the verification is determined to be successful. The first version number set includes at least one type identifier of BMC and version numbers of at least one firmware supported by the security kernel corresponding to different BMC type identifiers.

9. The method as described in claim 5, characterized in that, The verification of the second security kernel firmware based on the first version number set and the first version number to be verified specifically includes: When the type identifier of the first BMC is the same as the type identifier of a BMC in the first version number set, and the first version number to be verified is greater than or equal to the version number corresponding to that BMC type in the first version number set, the verification is determined to be successful. The first version number set includes at least one BMC type identifier and the minimum version number of the firmware supported by the security kernel corresponding to different BMC type identifiers; or... When the type identifier of the first BMC is the same as the type identifier of a BMC in the first version number set, and the first version number to be verified is greater than the version number corresponding to the BMC type in the first version number set, the verification is determined to be successful. The first version number set includes at least one type identifier of BMC and the maximum version number of firmware that is not supported by the security core corresponding to different BMC type identifiers.

10. A BMC firmware upgrade method, characterized in that, The method is applied to a first BMC, which includes a security core, a service core, and a second memory. The security core runs first security core firmware. The second memory stores a first version number set, which indicates either the version number of firmware that the security core does not support or the version number of firmware that the security core supports. The second memory is not accessible to the service core, which runs first service core firmware. The second memory also stores a second version number set, which indicates either the version number of firmware that the service core does not support or the version number of firmware that the service core supports. The method includes: In response to the upgrade command, the system obtains the second security core firmware and the first version number to be verified, the second service core firmware and the second version number to be verified from the upgrade package. The first version number to be verified is the version number of the second security core firmware; the second version number to be verified is the version number of the second service core firmware. The first version number set and the second version number set are obtained from the second memory; the first version number set includes the type identifier of the BMC, and indicates the firmware version number that the corresponding security kernel supports or does not support based on different type identifiers; The second security core firmware is verified based on the first version number set and the first version number to be verified; the second service core firmware is verified based on the second version number set and the second version number to be verified. If the verification is successful, the first security core firmware will be upgraded to the second security core firmware, and the first service core firmware will be upgraded to the second service core firmware.

11. The method as described in claim 10, characterized in that, The verification of the second security kernel firmware based on the first version number set and the first version number to be verified specifically includes: The verification is successful when the first version number to be verified is different from all version numbers in the first version number set, wherein the first version number set includes version numbers of at least one firmware that is not supported by the security kernel; or... The verification is successful when the first version number to be verified matches any version number in the first version number set, wherein the first version number set includes version numbers of at least one firmware supported by the security kernel; or... The verification is successful when the first version number to be verified is greater than or equal to the version number in the first set of version numbers, wherein the first set of version numbers includes the minimum version number of the firmware supported by the security kernel; or... When the first version number to be verified is greater than the version number in the first set of version numbers, the verification is determined to be successful. The first set of version numbers includes the maximum version number of firmware that is not supported by the security kernel.

12. The method as described in claim 10, characterized in that, The verification of the second service core firmware based on the second version number set and the second version number to be verified specifically includes: The verification is successful when the second version number to be verified is different from all version numbers in the second version number set, wherein the second version number set includes version numbers of at least one firmware that is not supported by the service core; or... The verification is successful when the second version number to be verified matches any version number in the second version number set, wherein the second version number set includes version numbers of at least one firmware supported by the service core; or, The verification is successful when the second version number to be verified is greater than or equal to the version number in the second version number set, wherein the second version number set includes the minimum firmware version number supported by the service core; or, When the second version number to be verified is greater than the version number in the second version number set, the verification is determined to be successful. The second version number set includes the maximum version number of firmware that is not supported by the service core.

13. A chip, characterized in that, The chip is used to perform the method as described in any one of claims 1-9, or the chip is used to perform the method as described in any one of claims 10-12.

14. A computing device, characterized in that, The computing device includes a central processing unit and a BMC, the BMC being configured to perform the method as described in any one of claims 1-9, or the BMC being configured to perform the method as described in claims 10-12.

Images