Recovery recovery method for BIOS (Basic Input / Output System) firmware

Abstract

The invention relates to a recovery method for BIOS firmware, and belongs to the field of computer systems. According to the method, backup operation is carried out on the content of the FVMAINCOMPACT, an original FVMAINCOMPACTMAIN on a PcdBackFvBase address is normally started and executed, when the original is damaged, a backup FVMAINCOMPACTBACKUP on the PcdFvBase Address address is executed, the content is transmitted to the DXE from the PEI stage in the form of establishing Hob, and updating of the original by the backup is completed in the DXE; during compiling, an SHA256 hash value of an original is calculated and stored in Flash, and when firmware is started and runs, whether a starting file changes or not is judged by comparing the hash value. According to the method, the problems that the mainboard has no external storage equipment condition, and the firmware startup fault needs to be recovered by Recovery are solved; the SHA256 hash value is calculated through a tool during compiling, and the Sha256 hash value is dynamically calculated through an OpenslLib standard library during starting, so that the basis for judging the damage of the firmware file is enhanced.

Description

Technical Field

[0001] The invention belongs to the field of computer systems, and in particular relates to a recovery method for BIOS firmware. Background Art

[0002] BIOS firmware is a binary program that is fixed on the motherboard Flash and plays an important role in the motherboard startup and operating system boot. If the motherboard encounters abnormal power failure or peripheral circuit failure, it may cause unintended local byte changes in the binary file content, and the restart process may cause unexpected failures, which may cause the system to start in an incompletely functional or incompletely functional form, or even abnormally and interrupt the startup. At this time, it is necessary to restore the firmware to a normal or initial state. This method is called Recovery in the industry's common standards.

[0003] The premise for the Recovery function to take effect is that the BIOS firmware can boot to the PEI stage, and read the recovery file in the external storage device in the PEI stage (usually only the main area FVMAIN_COMPACT needs to be restored), establish the Hob (Hand-OffBlock) and pass it to the DXE stage to call the SPI driver to implement recovery by updating the firmware.

[0004] At present, the method to judge whether FVMAIN_COMPACT has changed is mainly to judge the file identifier, the characters '_', 'F', 'V', and 'H' at fixed positions in the file. If these four characters change, FVMAIN_COMPACT changes. External storage devices include SATA, USB, NVMe, and CD / DVD. The disadvantage is that only judging the file type identifier cannot determine the integrity of the file, and the judgment conditions have limitations. In addition, FVMAIN_COMPACT is loaded in the PEI stage, and the SPI driver for updating the firmware needs to be executed in the DXE stage. The file is read by an external storage device, and the enabling of the device and the file system read and write functions in the PEI stage need to be implemented. In addition, for those motherboards that do not have the conditions for external storage devices, this method cannot achieve recovery. Summary of the invention

[0005] 1. Technical issues to be resolved

[0006] The technical problem to be solved by the present invention is how to provide a recovery method for BIOS firmware to solve the problems existing in the recovery of the existing BIOS firmware.

[0007] (II) Technical solution

[0008] In order to solve the above technical problem, the present invention proposes a BIOS firmware recovery method, which specifically includes the following steps:

[0009] Compilation phase completed:

[0010] S11. In the .fdf file, double-pack the FVMAIN_COMPACT content. The original file FVMAIN_COMPACT_MAIN is stored at the offset of PcdFvBaseAddress, and the backup file FVMAIN_COMPACT_BACKUP is stored at the offset of PcdBackFvBaseAddress. The BIOS firmware binary file including the original file and the backup is compiled and generated.

[0011] S12. Calculate the hash value of the FVMAIN_COMPACT content and store the result FixedBuildHash in the .fdf file at the location PcdHashValue.

[0012] The firmware boot phase is complete:

[0013] S21, BIOS firmware boots to the PEI stage, when initializing the platform-related drivers, load the FVMAIN_COMPACT_MAIN original file from the Flash location PcdFvBaseAddress to the memory;

[0014] S22, calling the function interface to calculate the hash value RuntimeHash of the content of FVMAIN_COMPACT_MAIN loaded into the memory in real time;

[0015] S23, read the hash value FixedBuildHash calculated during compilation from the Flash location PcdHashValue;

[0016] S24. Compare RuntimeHash and FixedBuildHash;

[0017] S25. If RuntimeHash and FixedBuildHash are the same, then Hob is established to pass FVMAIN_COMPACT_MAIN to the subsequent startup phase as the execution content of the subsequent firmware startup phase;

[0018] If RuntimeHash and FixedBuildHash are different, load FVMAIN_COMPACT_BACKUP from Flash location PcdBackFvBaseAddress to memory, call the function interface, and calculate the hash value RuntimeBackHash of the FVMAIN_COMPACT_BACKUP content loaded into memory in real time; compare RuntimeBackHash and FixedBuildHash, if they are equal, establish Hob to pass FVMAIN_COMPACT_BACKUP to the subsequent startup stage as the execution content of the subsequent startup stage, and establish the startup mode Hob, record BootMode as UpdateFromFlash is TRUE; if they are not equal, the main backup files are damaged, the startup cannot continue, and the process is exited;

[0019] S26, BIOS firmware boots to DXE stage, and obtains boot mode UpdateFromFlash from Hob;

[0020] S27. If the acquisition of the boot mode fails, that is, the boot from the backup file is not triggered, the firmware boot continues; if the acquisition of the boot mode succeeds and UpdateFromFlash is TRUE, the SPI interface is called to update the content of FVMAIN_COMPACT_BACKUP to the location of PcdFvBaseAddress.

[0021] (III) Beneficial effects

[0022] The present invention provides a BIOS firmware recovery method, which has the following beneficial effects:

[0023] 1. The form of storing two boot-related files on one Flash solves the problem of firmware boot failure requiring recovery in some application scenarios where the motherboard has no external storage device conditions;

[0024] 2. The SHA256 hash value is calculated by the compile-time tool and the OpensllLib standard library dynamically calculates the Sha256 hash value at startup, which strengthens the basis for judging whether the firmware file is damaged. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0026] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0027] The present invention uses the Flash storing the BIOS firmware as a storage device for the files required for the Recovery firmware. When the firmware is compiled, the original file of the FVMAIN_COMPACT area required by the Recovery is double-packed. When the original FVMAIN_COMPACT changes, the original is updated using the backup of the original. No external storage device is required, and the required update can be automatically completed. In addition, the present invention uses a tool to perform SHA256 verification on the FVMAIN_COMPACT file during compilation, and stores the unique verification value in the Flash as a reference value. Each time the firmware is started, FVMAIN_COMPACT is read into the memory, and the SHA256 interface of the OpensllLib standard library is used to complete the secondary verification during runtime, and the reference value stored in the Flash is compared to determine whether FVMAIN_COMPACT has changed. The probability of reading the file type identifier and judging errors is reduced.

[0028] The .fdf file determines the files or data content to be compiled, which is then compiled to generate binary firmware and finally burned into Flash.

[0029] The original definition of FVMAIN_COMPACT in the .fdf file is as follows:

[0030] File Type(FV)PcdFileStratOffset|PcdFIleLength

[0031] FVMAIN_COMPACT

[0032] FV is the Firmware Volume file type (.fdf can define types including firmware volume type FV, hexadecimal data type DATA, UEFI driver type INF, and binary file type FILE FREEFORM, etc.). PcdFileStratOffset and PcdFIleLengthPcd are reusable data of the platform configuration database PCD (Platform Configuration Database) in the UEFI standard type. The data type is UINT64. PcdFileStratOffset is the relative position data of FVMAIN_COMPACT in the final generated firmware file, and PcdFIleLength is the file size data of FVMAIN_COMPACT.

[0033] After the firmware is burned into Flash and loaded into memory at startup, the relative position of FVMAIN_COMPACT in the firmware in memory remains unchanged. Therefore, the content of the FVMAIN_COMPACT file can be read at runtime by accessing the content of PcdFileStratOffset in memory.

[0034] In the method of the present invention, the original file of the FVMAIN_COMPACT area required by Recovery is packaged in duplicate during firmware compilation, and the PcdFileStratOffset of the original file and the backup file are changed to PcdFvBaseAddress and PcdBackFvBaseAddress.

[0035] The present invention provides a BIOS firmware recovery method, which specifically comprises the following steps:

[0036] Compilation phase completed:

[0037] S11. In the .fdf file, double-pack the FVMAIN_COMPACT content. The original file FVMAIN_COMPACT_MAIN is stored at the offset of PcdFvBaseAddress, and the backup file FVMAIN_COMPACT_BACKUP is stored at the offset of PcdBackFvBaseAddress. The BIOS firmware binary file including the original file and the backup is compiled and generated.

[0038] S12. Calculate the hash value of the FVMAIN_COMPACT content and store the result FixedBuildHash in the .fdf file at the location PcdHashValue.

[0039] The firmware boot phase is complete:

[0040] S21, BIOS firmware boots to the PEI stage, when initializing the platform-related drivers, load the FVMAIN_COMPACT_MAIN original file from the Flash location PcdFvBaseAddress to the memory;

[0041] S22, calling the function interface to calculate the hash value RuntimeHash of the content of FVMAIN_COMPACT_MAIN loaded into the memory in real time;

[0042] S23, read the hash value FixedBuildHash calculated during compilation from the Flash location PcdHashValue;

[0043] S24. Compare RuntimeHash and FixedBuildHash;

[0044] S25. If RuntimeHash and FixedBuildHash are the same, then Hob is established to pass FVMAIN_COMPACT_MAIN to the subsequent startup phase as the execution content of the subsequent firmware startup phase;

[0045] If RuntimeHash and FixedBuildHash are different, load FVMAIN_COMPACT_BACKUP from Flash location PcdBackFvBaseAddress to memory, call the function interface, and calculate the hash value RuntimeBackHash of the FVMAIN_COMPACT_BACKUP content loaded into memory in real time; compare RuntimeBackHash and FixedBuildHash, if they are equal, establish Hob to pass FVMAIN_COMPACT_BACKUP to the subsequent startup stage as the execution content of the subsequent startup stage, and establish the startup mode Hob, record BootMode as UpdateFromFlash is TRUE; if they are not equal, the main backup files are damaged, the startup cannot continue, and the process is exited;

[0046] S26, BIOS firmware boots to DXE stage, and obtains boot mode UpdateFromFlash from Hob;

[0047] S27. If the acquisition of the boot mode fails, that is, the boot from the backup file is not triggered, the firmware boot continues; if the acquisition of the boot mode succeeds and UpdateFromFlash is TRUE, the SPI interface is called to update the content of FVMAIN_COMPACT_BACKUP to the location of PcdFvBaseAddress.

[0048] Embodiment 1:

[0049] Compilation phase completed:

[0050] S11. In the .fdf file, double-pack the content of FVMAIN_COMPACT. The original file FVMAIN_COMPACT_MAIN is stored at the offset of PcdFvBaseAddress, and the backup file FVMAIN_COMPACT_BACKUP (with the same content as FVMAIN_COMPACT_MAIN) is stored at the offset of PcdBackFvBaseAddress. Compile and generate a BIOS firmware binary file including the original file and the backup file.

[0051] S12. Use the SHA256 verification tool to calculate the SHA256 hash value of the FVMAIN_COMPACT part, and store the result FixedBuildSha256 in the .fdf file at the location PcdSha256Value.

[0052] The firmware boot phase is complete:

[0053] S21, BIOS firmware boots to the PEI stage, when initializing the platform-related drivers, load the FVMAIN_COMPACT_MAIN original file from the Flash location PcdFvBaseAddress to the memory;

[0054] S22, call the SHA256 function interface of the OpensllLib standard library to calculate the hash value RuntimeSha256 of the FVMAIN_COMPACT_MAIN content loaded into the memory in real time;

[0055] S23, read the hash value FixedBuildSha256 calculated during compilation from the Flash location PcdSha256Value;

[0056] S24. Compare RuntimeSha256 and FixedBuildSha256;

[0057] S25. If RuntimeSha256 and FixedBuildSha256 are the same, then Hob is established to pass FVMAIN_COMPACT_MAIN to the subsequent startup phase as the execution content of the subsequent firmware startup phase;

[0058] If RuntimeSha256 and FixedBuildSha256 are different, load FVMAIN_COMPACT_BACKUP from the Flash location PcdBackFvBaseAddress to the memory, call the SHA256 function interface of the OpensllLib standard library, and calculate the hash value RuntimeBackSha256 of the FVMAIN_COMPACT_BACKUP content loaded into the memory in real time; compare RuntimeBackSha256 and FixedBuildSha256, if they are equal, establish Hob to pass FVMAIN_COMPACT_BACKUP to the subsequent startup stage as the execution content of the subsequent startup stage, and establish the startup mode Hob, record BootMode as UpdateFromFlash is TRUE; if they are not equal, the main backup files are damaged, the startup cannot continue, and the process is exited;

[0059] S26, BIOS firmware boots to DXE stage, and obtains boot mode UpdateFromFlash from Hob;

[0060] S27. If the acquisition of the boot mode fails, that is, the boot from the backup file is not triggered, the firmware boot continues; if the acquisition of the boot mode succeeds and UpdateFromFlash is TRUE, the SPI interface is called to update the content of FVMAIN_COMPACT_BACKUP to the location of PcdFvBaseAddress.

[0061] The key points of the present invention are:

[0062] 1. Back up the content of FVMAIN_COMPACT. When the original FVMAIN_COMPACT_MAIN is started normally, the backup FVMAIN_COMPACT_BACKUP at the PcdFvBaseAddress address is executed when the original is destroyed. The content is transferred from the PEI stage to DXE by establishing Hob, and the backup is updated to the original in DXE.

[0063] 2. Calculate the SHA256 hash value of the original and store it in Flash during compilation. When the firmware starts running, calculate the content of the FVMAIN_COMPACT file loaded into the memory again, and call the OpensllLib standard library in the code to dynamically calculate its SHA256 hash value. By comparing the hash value, determine whether the startup file has changed.

[0064] The present invention has the following beneficial effects:

[0065] 1. The form of storing two boot-related files on one Flash solves the problem of firmware boot failure requiring recovery in some application scenarios where the motherboard has no external storage device conditions;

[0066] 2. The SHA256 hash value is calculated by the compile-time tool and the OpensllLib standard library dynamically calculates the Sha256 hash value at startup, which strengthens the basis for judging whether the firmware file is damaged.

[0067] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A BIOS firmware recovery method, characterized in that: The method specifically comprises the following steps: Compilation phase completed: S11. In the .fdf file, double-pack the FVMAIN_COMPACT content. The original file FVMAIN_COMPACT_MAIN is stored at the offset of PcdFvBaseAddress, and the backup file FVMAIN_COMPACT_BACKUP is stored at the offset of PcdBackFvBaseAddress. The BIOS firmware binary file including the original file and the backup is compiled and generated. S12. Calculate the hash value of the FVMAIN_COMPACT content and store the result FixedBuildHash in the .fdf file at the location PcdHashValue. The firmware boot phase is complete: S21, BIOS firmware boots to the PEI stage, when initializing the platform-related drivers, load the FVMAIN_COMPACT_MAIN original file from the Flash location PcdFvBaseAddress to the memory; S22, calling the function interface to calculate the hash value RuntimeHash of the content of FVMAIN_COMPACT_MAIN loaded into the memory in real time; S23, read the hash value FixedBuildHash calculated during compilation from the Flash location PcdHashValue; S24. Compare RuntimeHash and FixedBuildHash; S25. If RuntimeHash and FixedBuildHash are the same, then Hob is established to pass FVMAIN_COMPACT_MAIN to the subsequent startup phase as the execution content of the subsequent firmware startup phase; If RuntimeHash and FixedBuildHash are different, load FVMAIN_COMPACT_BACKUP from Flash location PcdBackFvBaseAddress to memory, call the function interface, and calculate the hash value RuntimeBackHash of the content of FVMAIN_COMPACT_BACKUP loaded into memory in real time; Compare RuntimeBackHash and FixedBuildHash. If they are equal, create Hob to pass FVMAIN_COMPACT_BACKUP to the subsequent startup phase as the execution content of the subsequent startup phase. In addition, create the startup mode Hob and record BootMode as UpdateFromFlash is TRUE. If they are not equal, the primary backup files are damaged, the startup cannot continue, and the process is exited; S26, BIOS firmware boots to DXE stage, and obtains boot mode UpdateFromFlash from Hob; S27. If the acquisition of the boot mode fails, that is, the boot from the backup file is not triggered, the firmware boot continues; if the acquisition of the boot mode succeeds and UpdateFromFlash is TRUE, the SPI interface is called to update the content of FVMAIN_COMPACT_BACKUP to the location of PcdFvBaseAddress.

2. The BIOS firmware recovery method according to claim 1, wherein: Use the SHA256 checksum tool to calculate the SHA256 hash value of the FVMAIN_COMPACT part and store the result FixedBuildSha256 in the .fdf file at PcdSha256Value.

3. The BIOS firmware recovery method according to claim 2, wherein: In S22, the SHA256 function interface is called to calculate the hash value RuntimeSha256 of the FVMAIN_COMPACT_MAIN content loaded into the memory in real time.

4. The BIOS firmware recovery method according to claim 3, wherein: In S25, the SHA256 function interface is called to calculate the hash value RuntimeBackSha256 of the FVMAIN_COMPACT_BACKUP content loaded into the memory in real time.

5. The BIOS firmware recovery method according to claim 4, characterized in that: Use the SHA256 function interface of the OpensllLib standard library.

6. The BIOS firmware recovery method according to any one of claims 1 to 5, characterized in that: The .fdf file determines the files or data content to be compiled, and after compilation, a binary firmware is generated, which is finally burned into the Flash.

7. The BIOS firmware recovery method according to claim 6, wherein: The definition of FVMAIN_COMPACT in the .fdf file is as follows: File TypePcdFileStratOffset|PcdFIleLength FVMAIN_COMPACT Among them, FV is the Firmware Volume file type, PcdFileStratOffset and PcdFIleLengthPcd are reusable data of the platform configuration database PCD in the UEFI standard type, the data type is UINT64, PcdFileStratOffset is the relative position data of FVMAIN_COMPACT in the final generated firmware file, and PcdFIleLength is the file size data of FVMAIN_COMPACT.

8. The BIOS firmware recovery method according to claim 7, wherein: The defined types include: firmware volume type FV, hexadecimal data type DATA, UEFI driver type INF, and binary file type FILE FREEFORM.

9. The BIOS firmware recovery method according to claim 7, wherein: The firmware is burned into Flash and loaded into memory at startup. The relative position of FVMAIN_COMPACT in the firmware in memory remains unchanged.

10. The BIOS firmware recovery method according to claim 7, wherein: During runtime, the Flash storing the BIOS firmware is used as the storage device for the files required for the Recovery firmware. When compiling the firmware, the original files in the FVMAIN_COMPACT area required by the Recovery are packaged in duplicate. When the original FVMAIN_COMPACT changes, the backup of the original is used to update the original. The required updates can be automatically completed without an external storage device.

Images