Method and apparatus for updating a boot path whitelist, electronic device, and storage medium

Abstract

This application provides a method, apparatus, electronic device, and readable storage medium for updating a boot path whitelist. The method includes: obtaining boot path information to be updated; comparing the boot path information to be updated with a pre-set whitelist to obtain a whitelist comparison result, wherein the whitelist includes multiple boot path information entries in the pre-set boot path whitelist; when the whitelist comparison result shows that the boot path information to be updated differs from all boot path information entries in the boot path whitelist, updating a platform configuration database variable based on the boot path information to be updated to obtain a whitelist update result, wherein the whitelist is assigned a value in the platform configuration database variable; and packaging the firmware file corresponding to the whitelist update result to obtain a first whitelist update result. This improves the efficiency of updating the boot path whitelist, increases the freedom and flexibility of booting the operating system, and enhances the user experience.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for updating a boot path whitelist. Background Technology

[0002] Due to the frequent occurrence of serious security vulnerabilities and the increasingly widespread use of servers across various industries, server security has become an indispensable part of server usage. In particular, setting security policies for the server's boot into the OS is receiving increasing attention.

[0003] To address these needs, existing technologies often restrict operating systems through pre-set whitelists. Only operating systems on the whitelist can be displayed and booted, greatly improving server security. However, this whitelist design limits the range of operating systems users can install and run. Furthermore, as operating systems are continuously updated, the whitelist cannot be maintained and updated in a timely manner, restricting user freedom and flexibility and resulting in a poor user experience. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and readable storage medium for updating a boot path whitelist. The technical solution provided by this application, when determining that the boot path information differs from the information in the whitelist pre-stored in the firmware volume space, achieves rapid whitelist updates by updating the platform configuration database variables corresponding to the whitelist and repackaging the corresponding firmware files. This solves the problems of untimely whitelist updates, limited freedom and flexibility during operating system startup, and poor user experience in existing technologies.

[0005] Firstly, this application provides a method for updating a startup path whitelist, the method comprising:

[0006] Obtain the startup path information to be updated;

[0007] The startup path information to be updated is compared with the pre-set whitelist to obtain the whitelist comparison result. The whitelist includes multiple startup path information from the pre-set startup path whitelist.

[0008] When the whitelist comparison result shows that the startup path information to be updated is different from multiple startup path information in the startup path whitelist, the platform configuration database variable is updated according to the startup path information to be updated to obtain the whitelist update result. The whitelist is assigned to the platform configuration database variable.

[0009] Package the firmware files corresponding to the whitelist update results to obtain the first whitelist update result.

[0010] Optionally, the startup path whitelist update method provided in this application also includes:

[0011] By locating and accessing the firmware volume space using the pre-set volume base address, a whitelist list can be obtained.

[0012] Optionally, the startup path whitelist update method provided in this application also includes:

[0013] In the firmware volume space of the basic input / output system, a first platform configuration database variable is set, wherein the first platform configuration database variable is used to store a whitelist name list;

[0014] Set a second platform configuration database variable in the firmware volume space of the basic input / output system. The second platform configuration database variable is used to store a whitelist of boot paths.

[0015] The values ​​of the whitelist names in the startup path whitelist are assigned to the first platform configuration database variables to obtain the assigned first platform configuration database variables.

[0016] The whitelist of startup paths in the startup path whitelist is assigned to the second platform configuration database variable, resulting in the assigned second platform configuration database variable.

[0017] Optionally, the startup path whitelist update method provided in this application also includes:

[0018] The startup path information to be updated is checked according to the pre-set startup path specification rules, and the checked startup path information to be updated is obtained.

[0019] Optionally, the startup path whitelist update method provided in this application also includes:

[0020] Determine the startup mode of the basic input / output system and obtain the startup mode determination result;

[0021] When the boot mode determination result is the unified extensible firmware interface operating system whitelist, the boot item traversal action is performed on the first whitelist update result to obtain the number of boot items;

[0022] When the number of startup items is greater than 0, the system will boot into the operating system corresponding to the first whitelist update result.

[0023] Optionally, the startup path whitelist update method provided in this application also includes:

[0024] Package the firmware file to obtain the intermediate packaging result;

[0025] The first whitelist update result is obtained by signing the intermediate packaged result with the private key.

[0026] Optionally, the startup path whitelist update method provided in this application also includes:

[0027] Perform a space memory assessment on the firmware volume space and obtain the space memory assessment result;

[0028] When the space memory judgment result is that the firmware volume space is insufficient, delete the boot path whitelist in the firmware volume space and adjust the whitelist list update result to obtain the adjusted whitelist list.

[0029] The firmware files corresponding to the adjusted whitelist are packaged to obtain the second whitelist update result.

[0030] Secondly, this application also provides a startup path whitelist update device, comprising:

[0031] Update the startup path acquisition module to obtain startup path information to be updated;

[0032] The whitelist comparison module is used to compare the startup path information to be updated with the pre-set whitelist list to obtain the whitelist comparison result. The whitelist list includes multiple startup path information in the pre-set startup path whitelist.

[0033] The list update module is used to update the platform configuration database variables based on the startup path information to be updated when the whitelist comparison result is that the startup path information to be updated is different from multiple startup path information in the startup path whitelist, so as to obtain the whitelist list update result. The whitelist list is assigned to the platform configuration database variables.

[0034] The first whitelist update module is used to package the firmware file corresponding to the whitelist update result to obtain the first whitelist update result.

[0035] Thirdly, this application also provides an electronic device including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the boot path whitelist update method as described in the first aspect.

[0036] Fourthly, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the startup path whitelist update method as described in the first aspect.

[0037] The technical solution provided in this application, since the whitelist is pre-stored through platform configuration database variables, when the whitelist needs to be updated, only the platform configuration database variables need to be updated according to the boot path information to be updated, and the updated binary data is repackaged to obtain the first whitelist update result. The update effect of the boot path whitelist can be achieved without updating the link variable elink and recompiling the BIOS binary firmware file. This improves the update efficiency of the boot path whitelist, increases the user's freedom and flexibility in booting the operating system, and thus improves the user's boot path whitelist experience.

[0038] The above description is merely an overview of the technical solution provided in this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are described below. Attached Figure Description

[0039] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0040] Figure 1 This is one of the schematic diagrams of the startup path whitelist update method provided in the embodiments of this application;

[0041] Figure 2 This is the second schematic diagram of the startup path whitelist update method provided in the embodiments of this application;

[0042] Figure 3 This is the third schematic diagram of the startup path whitelist update method provided in the embodiments of this application;

[0043] Figure 4 This is the fourth schematic diagram of the startup path whitelist update method provided in the embodiments of this application;

[0044] Figure 5 This is the fifth schematic diagram of the startup path whitelist update method provided in the embodiments of this application;

[0045] Figure 6 This is the sixth schematic diagram of the startup path whitelist update method provided in the embodiments of this application;

[0046] Figure 7 This is the seventh schematic diagram of the startup path whitelist update method provided in the embodiments of this application;

[0047] Figure 8 This is one example of updating the startup path whitelist provided in this application;

[0048] Figure 9 This is the second example of updating the startup path whitelist provided in this application;

[0049] Figure 10 This is a schematic diagram of the startup path whitelist update device provided in an embodiment of this application;

[0050] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0052] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0053] The Basic Input Output System (BIOS) is a system program used to control the server motherboard, typically stored on a read-only memory (ROM) chip on the motherboard. It contains the computer's basic input / output programs, system settings, power-on self-test (POST) programs, and system startup programs, thus providing the computer with the lowest-level and most direct hardware configuration functions. As servers are increasingly used across various industries, they play an increasingly important role in data acquisition and processing. However, frequent serious security vulnerabilities in the BIOS have severely impacted user experience and information security, hindering its widespread adoption. Security policies for booting the operating system (OS) on a server typically involve the BIOS pre-creating a whitelist of OS information for various control programs. This includes configuring a list of allowed operating systems to boot and install. Only OSes listed in the whitelist are displayed in the Unified Extensible Firmware Interface (UEFI) settings interface and booted via hotkeys displayed on the server's power-on screen, such as F2, F10, or Del. Other operating systems are blocked. This prevents unauthorized OSs from booting, protects against program tampering by non-standard operating systems, and addresses incompatibility issues between programs or hardware settings and non-standard OSs, significantly improving server security. Configuring the UEFI OS whitelist allows administrators to more easily manage which operating systems are allowed to install and run on the server. The whitelisted operating systems are certified and authorized, ensuring security and improving server operability, reducing administrator workload and operational complexity. Furthermore, the UEFI OS whitelist function supports security features such as Secure Boot, which requires the UEFI OS whitelist to function. By using a whitelist, you can ensure that only trusted operating systems can boot and prevent malware from interfering with the boot process.

[0054] However, this UEFIOS whitelist setting restricts the range of operating systems users can install and run. Only operating systems listed in the whitelist are allowed to boot, limiting user freedom and flexibility. Existing whitelist configuration and management require BIOS firmware developers to modify the value of the link variable `elink` defined in the BIOS program, copy the whitelist paths to be updated to the link variable, and recompile the BIOS binary firmware file to achieve UEFIOS whitelist adaptation and maintenance. This whitelist update method requires significant R&D resources and manpower to develop and test new BIOS firmware versions, and necessitates timely version release processes. Furthermore, compiling BIOS program code and the version release process require a high level of expertise, significantly increasing maintenance costs and complexity.

[0055] To address the issues of complex UEFIOS whitelist maintenance methods and the need for frequent BIOS releases when the OS boot path or boot name changes, this application provides a technical solution that reserves a firmware volume (FV) space in the BIOS to store the UEFIOS whitelist. A "change UEFIOS whitelist" tool is defined, which accesses the BIOS firmware file's FV space through a specific FV Base Address agreed upon by the BIOS, reads the UEFIOS whitelist from the BIOS firmware file, adds to, modifies, and deletes entries in the list, and then repackages the modified binary data into the BIOS firmware to achieve rapid UEFIOS whitelist updates.

[0056] The following description, in conjunction with the accompanying drawings, details the boot path whitelist update method, apparatus, electronic device, and non-volatile readable storage medium provided in this application through specific embodiments and application scenarios.

[0057] The first embodiment of this application relates to a method for updating a startup path whitelist, such as... Figure 1 As shown, it includes:

[0058] Step 101: Obtain the startup path information to be updated;

[0059] Step 102: Compare the startup path information to be updated with the pre-set whitelist to obtain the whitelist comparison result. The whitelist includes multiple startup path information in the pre-set startup path whitelist.

[0060] Step 103: When the whitelist comparison result shows that the startup path information to be updated is different from multiple startup path information in the startup path whitelist, update the platform configuration database variable according to the startup path information to be updated to obtain the whitelist update result. The whitelist is assigned to the platform configuration database variable.

[0061] Step 104: Package the firmware file corresponding to the whitelist update result to obtain the first whitelist update result.

[0062] Specifically, the boot path whitelist update method provided in this application first obtains the boot path information to be updated and compares it with multiple boot path information in a pre-set whitelist to obtain the whitelist comparison result. When the whitelist comparison result shows that the boot path information to be updated is different from multiple boot path information pre-recorded in the whitelist, it is determined that the boot path information to be updated needs to be added to the whitelist. The whitelist is then updated according to the boot path information to be updated, and the corresponding data or firmware files are packaged. At this time, the data related to the boot path information to be updated is quickly written into the whitelist, and the corresponding operating system is also included in the whitelist. Users can then boot the newly added operating system under the server boot process, improving the scalability and manageability of the system's boot items or operating system.

[0063] For example, BIOS systems often restrict boot items or operating systems during startup using a UEFIOS whitelist. The method provided in this application, after obtaining the information of the boot path to be added to the whitelist, compares it with the UEFIOS whitelist list pre-stored in a specific FV space reserved in the BIOS firmware file. When the comparison reveals that the obtained boot path information is different from multiple pre-stored boot path information in the UEFIOS whitelist (e.g., differences in individual bits of binary data), the boot path information to be updated is written into the whitelist, and the modified binary data or firmware file is packaged to achieve rapid updating of the UEFIOS whitelist.

[0064] Since the whitelist's startup path and name are stored in platform configuration database variables, such as the global variable PCD, updating the whitelist can be achieved simply by modifying the global variable PCD.

[0065] This application allows for updating the whitelist using development tools. For example, a tool called "change UEFIOS white list Tool" can be developed to load and parse BIOS binary image files to obtain the whitelist. After comparison, if the boot path information to be updated is found to be different from the pre-stored boot path information, the "change UEFIOS white list Tool" can be used to add the UEFIOS whitelist. The "change UEFIOS white list Tool" can then be used to repackage the modified binary data corresponding to the modified UEFIOS whitelist into the BIOS firmware.

[0066] In the technical solution provided in this application, since the whitelist is pre-stored through platform configuration database variables, when the whitelist needs to be updated, compared to the prior art which requires modifying the value of the elink link variable defined in the BIOS program, reassigning the whitelist path to be updated to the link variable, and recompiling the BIOS binary firmware file, the technical solution provided in this application only needs to update the platform configuration database variables according to the boot path information to be updated, and repackage the updated binary data to add the whitelist path to the whitelist. This improves the efficiency of updating the boot path whitelist, increases the user's freedom and flexibility in booting the operating system, and thus improves the user's experience of using the boot path whitelist.

[0067] Based on the above implementation methods, such as Figure 2 As shown, the startup path whitelist update method provided in this application includes the following steps before step 102:

[0068] Step 105: Locate and access the firmware volume space using the pre-set volume base address to obtain the whitelist list.

[0069] Specifically, the boot path whitelist update method provided in this application can also obtain the whitelist list by accessing the FV space corresponding to the firmware file to obtain the content data stored at that address.

[0070] For example, this application can locate and access a specific FV space reserved in the BIOS firmware file based on the FV base address pre-defined by the BIOS, using the change UEFIOS white list tool. For example, it can access the FV space by FV base address and FV length, obtain the data stored at that address, and perform parsing and traversal on the stored data to obtain a whitelist of UEFIOS boot paths currently supported by the BIOS.

[0071] Based on the above implementation, since the rated technical solution provided in this application can locate and access the FV space through the pre-set FVBase Address, it improves the efficiency of obtaining the whitelist of UEFIOS boot path, thereby improving the whitelist update efficiency.

[0072] Based on the above implementation methods, such as Figure 3 As shown, the boot path whitelist is pre-stored in the firmware volume space of the basic input / output system. The whitelist includes a whitelist name list and a whitelist boot path list. In the boot path whitelist update method provided in this application, before step 102, it also includes:

[0073] Step 106: Set the first platform configuration database variable in the firmware volume space of the basic input / output system;

[0074] Step 107: Set the second platform configuration database variables in the firmware volume space of the basic input / output system;

[0075] Step 108: Assign values ​​to the first platform configuration database variable according to the whitelist name list in the startup path whitelist, and obtain the first platform configuration database variable after assignment;

[0076] Step 109: Assign the whitelisted startup paths from the startup path whitelist to the second platform configuration database variable to obtain the assigned second platform configuration database variable.

[0077] Specifically, the boot path whitelist update method provided in this application provides a method for writing the boot path into the whitelist before comparing the boot path information to be updated with the whitelist list. First, a FV space is pre-configured in the BIOS, for example, reserving more than 256 bytes of space to store the whitelist, and determining data such as the FV Base Address, End Address, and FV Length. Then, an FV Size is pre-configured in the BIOS, and variables A and B of the Platform Configuration Database (PCD) are defined in the program to store boot item names and paths. The key-value pair settings of the PCD are specified, describing the configuration, function switches, default settings, and other related parameters of the UEFIOS whitelist. For example, the first platform configuration database variable A stores the list of UEFIOS whitelist names, and the second platform configuration database variable stores the list of UEFIOS whitelist boot paths. The whitelist boot names and boot paths are then assigned to PCD variables A and B respectively.

[0078] Next, the BIOS boot mode is determined. When the boot mode is determined to be UEFI, the boot entries of all devices are traversed and the number of boot entries is obtained. When the number of boot entries is greater than 0 or not null, it is determined whether the entered boot path is in the whitelist. When it is determined that the boot path is not in the whitelist, the boot path is guided into the whitelist, thus realizing the function of pre-building the boot path whitelist.

[0079] Based on the above implementation, since the technical solution provided in this application stores the startup path whitelist information through the PCD variable and can perform actions such as modifying, deleting, and adding startup items corresponding to the whitelist information, it further improves the user's freedom and flexibility.

[0080] Based on the above implementation methods, such as Figure 4 As shown, the startup path whitelist update method provided in this application, after step 101 and before step 102, also includes:

[0081] Step 110: Check the startup path information to be updated according to the pre-set startup path specification rules to obtain the checked startup path information to be updated.

[0082] Specifically, in the startup path whitelist update method provided in this application, before comparing the startup path information to be updated with the whitelist, the startup path information to be updated can be checked according to the pre-set startup path specification rules. For startup path information to be updated that does not meet the startup path specification rules, an alarm is output and the system returns, and no further comparison or whitelist update actions are performed. Only startup path information to be updated that meets the startup path specification rules can participate in the subsequent comparison with multiple startup path information in the whitelist.

[0083] For example, the Change UEFIOS Whitelist Tool provides an interface for users to input the UEFIOS boot path to be added to the UEFIOS whitelist. After the boot path is entered, the Change UEFIOS Whitelist Tool automatically checks whether the entered UEFIOS boot path conforms to the pre-set UEFI specification rules, including but not limited to boot path length rules and boot path bootability specifications. Only when the entered UEFIOS boot path meets these UEFI specification rules can it participate in the subsequent comparison with the pre-stored whitelist. When the entered UEFIOS boot path does not meet these UEFI specification rules, an alarm message is issued, the subsequent comparison action is stopped, and the process returns until a new UEFIOS boot path is obtained before the UEFI specification rules are checked again.

[0084] Furthermore, the automatic checking action provided in this application is not limited to automatically checking the boot path information to be updated; it can also be automatically checked during the boot whitelist construction and storage into the BIOS FV space. During the boot whitelist construction process, the Change UEFIOS Whitelist Tool provides an interface for users to input the UEFIOS boot paths that need to participate in the UEFIOS whitelist construction. It automatically checks according to pre-set UEFI specification rules. Only when the entered UEFIOS boot path meets these UEFI specification rules can it participate in the subsequent whitelist construction action. When the entered UEFIOS boot path does not meet these UEFI specification rules, an alarm message is issued, subsequent comparison actions are stopped, and the process returns until a new UEFIOS boot path is obtained before resuming the UEFI specification rule check.

[0085] Furthermore, given that the FV Base Address, End Address, and FV Length are predetermined, when the entered boot path is compared with the boot path stored in the whitelist and it is determined that the entered boot path is different from the pre-stored boot path, the FV Length is judged according to the current boot path writing requirements. When the FV Length meets the current boot path writing requirements, the FV Base Address is accessed and the OS path is assigned to that address.

[0086] Based on the above implementation methods, the technical solution provided in this application can also check the boot path information to be updated, determine whether it conforms to the UEFI specification, and whether it is bootable. When the boot path information to be updated does not conform to the pre-set boot path specification rules, the comparison operation stops, avoiding the problem of non-standard boot paths occupying whitelist space after being added to the whitelist, thereby improving the usability of the boot path whitelist and the user experience.

[0087] Based on the above implementation methods, such as Figure 5 As shown, in the startup path whitelist update method provided in this application, after step 104, it also includes:

[0088] Step 111: Determine the startup mode of the basic input / output system and obtain the startup mode determination result;

[0089] Step 112: When the boot mode determination result is the unified extensible firmware interface operating system whitelist, perform a boot item traversal action on the first whitelist update result to obtain the number of boot items;

[0090] Step 113: When the number of startup items is greater than 0, boot into the operating system corresponding to the first whitelist update result.

[0091] Specifically, in the boot path whitelist update method provided in this application, after updating the whitelist, the boot mode is determined. If the boot mode is determined to be Legacy mode, subsequent actions are stopped and the process ends. If the boot mode is determined to be UEFI mode, the boot items of all devices are traversed and the number of boot items is counted. If the number of boot items is null or 0, subsequent actions are stopped and the process ends. If the number of boot items is not 0, the boot item is booted and the corresponding operating system is entered.

[0092] Furthermore, the boot path whitelist update method provided in this application is not limited to traversing boot items and performing boot actions after updating the whitelist; it can also update the whitelist after detecting the number of boot items and when the number of boot items is not zero. Specifically, the boot paths of these boot items are obtained and compared with the UEFIOS whitelist pre-stored in the FV space. When the comparison result shows that the boot paths of these boot items are different from the UEFIOS whitelist pre-stored in the FV space, the boot paths of these boot items are stored in the whitelist, for example, after EEPROM. When the comparison result shows that the boot paths of these boot items are the same as the UEFIOS whitelist pre-stored in the FV space, the boot item is directly booted and the corresponding operating system is entered.

[0093] Based on the above implementation method, the startup path whitelist update method provided in this application further includes, after step 102:

[0094] When the whitelist comparison result shows that the startup path information to be updated is the same as the startup path information, the whitelist comparison result will be output and displayed.

[0095] Specifically, in the boot path whitelist update method provided in this application, after obtaining the boot path information to be added to the whitelist, it is compared with the UEFIOS whitelist list in the specific FV space reserved in the BIOS firmware file. When the comparison finds that the obtained boot path information is different from the multiple boot path information pre-stored in the UEFIOS whitelist list, for example, when all bits of the binary data are the same, it means that the boot path information to be added to the whitelist has been pre-stored in the FV space reserved in the BIOS firmware file. No further modification to the whitelist list is performed, and the comparison result is output and displayed to prompt the user that the boot path information to be added to the whitelist has been entered into the whitelist.

[0096] Furthermore, the automatic checking action provided in this application is not limited to automatically checking the boot path information to be updated. During the stage of building and storing the boot whitelist into the BIOS FV space, when the whitelist is built one by one by entering the UEFIOS boot path, the whitelist comparison is also performed. When the comparison result is the same, the user is reminded that the corresponding UEFIOS boot path has been entered, and the user is reminded to enter other UEFIOS boot paths.

[0097] Based on the above implementation, the technical solution provided by this application can also avoid adding duplicate startup path information to the whitelist and occupying whitelist space when the startup path information to be updated is found to be the same as the startup path information in the pre-stored whitelist, thereby improving the usability of the startup path whitelist and user experience.

[0098] Based on the above implementation methods, such as Figure 6 As shown, in the startup path whitelist update method provided in this application, step 104 includes:

[0099] Step 141: Package the firmware file to obtain the intermediate packaging result;

[0100] Step 142: Sign the intermediate packaged result using the private key to obtain the first whitelist update result.

[0101] Specifically, the boot path whitelist update method provided in this application reads the signature part of the binary BIOS bin file using the change UEFIOS whitelist Tool, decrypts the signature part using a public key (e.g., a secure flash public key), loads the complete BIOS firmware, accesses the pre-set FV address and obtains the UEFIOS boot path data in the FV space, and when the whitelist corresponding to the UEFI OS whitelist is updated, the firmware file is repackaged using the change UEFIOS whitelist Tool to obtain the intermediate packaging result, and then re-signs it using a private key (e.g., a secure flash private key) to ensure the integrity and security of the BIOS firmware image.

[0102] Based on the above implementation methods, since the technical solution provided in this application can also package and sign firmware files, it enables rapid updates of the whitelist, thereby improving the update efficiency of the boot path whitelist while ensuring the integrity of the BIOS firmware image.

[0103] Based on the above implementation methods, such as Figure 7 As shown, in the startup path whitelist update method provided in this application, after step 103, it also includes:

[0104] Step 114: Perform a space memory assessment on the firmware volume space and obtain the space memory assessment result;

[0105] Step 115: When the space memory judgment result is that the firmware volume space is insufficient, delete the boot path whitelist in the firmware volume space and adjust the whitelist list update result to obtain the adjusted whitelist list.

[0106] Step 116: Package the firmware files corresponding to the adjusted whitelist to obtain the second whitelist update result.

[0107] Specifically, in the boot path whitelist update method provided in this application, when the comparison result shows that the boot path information to be updated is not pre-stored in the whitelist, the FV space needs to be checked for memory before writing the boot path information to be updated into the FV space. When it is determined that the FV space is insufficient, a prompt message indicating that the boot path information to be updated has failed to be added into the FV space is output, such as a prompt message indicating that the FV space is insufficient.

[0108] For example, the system iterates through the data stored in the FV and determines the storage space based on the reserved FV size. When the entered boot path cannot meet the FV size requirement of the reserved FV space UEFIOS whitelist, that is, when the FV size can no longer accommodate the newly added UEFIOS whitelist, the corresponding alarm message pops up.

[0109] Furthermore, this application can also perform actions such as deleting or reducing the whitelist and whitelist list, removing pre-stored boot paths and writing the boot path information to be updated into the FV space. In addition, before making a second attempt to write the boot path information to be updated into the FV space, another FV space memory check or judgment can be performed. If the boot path information to be updated can be stored, the whitelist and whitelist list are updated, and the firmware file corresponding to the updated binary data is packaged and signed to obtain the second whitelist update result.

[0110] The application does not impose restrictions on the conditions for deleting pre-stored startup path information. Restrictions can be imposed based on factors such as user frequency and the order in which whitelist entries are made. Alternatively, all startup path information in the whitelist can be deleted and re-added.

[0111] Based on the above implementation, since the technical solution provided by this application can delete the pre-stored startup path information and store new startup path information when the whitelist space is full, it realizes the rapid deletion and updating of the whitelist, improves the use effect of the whitelist, and thus enhances the user's freedom and flexibility when using the startup path whitelist.

[0112] Based on the above implementation methods, such as Figure 8 As shown, this application also provides a specific example of a process for updating the whitelist and booting into the corresponding operating system:

[0113] First, the BIOS program reserves FV space in advance and defines PCD variable lists to store UEFIOS whitelist names. Then, based on the OS name, a corresponding PCD variable list is defined to store the UEFIOS whitelist path. Next, the boot mode is determined. If Legacy mode is detected, subsequent actions are stopped and the process ends. If UEFI mode is detected, all boot entries for all devices are traversed and the number of boot entries is counted. If the number of boot entries is null or 0, subsequent actions are stopped and the process ends. If the number of boot entries is not 0, the boot paths of these boot entries are obtained and compared with the UEFIOS whitelist pre-stored in the FV space. If the comparison result shows that the boot paths of these boot entries are different from the UEFIOS whitelist pre-stored in the FV space, the boot paths of these boot entries are stored in the whitelist (e.g., after EEPROM, the boot entry is booted to enter the corresponding operating system). If the comparison result shows that the boot paths of these boot entries are the same as the UEFIOS whitelist pre-stored in the FV space, the boot entry is directly booted to enter the corresponding operating system.

[0114] Among them, such as Figure 9 As shown, this application also provides a specific comparison process example:

[0115] After obtaining and parsing the BIOS image file, the system accesses the FV Base Addresses, which stores the UEFIOS whitelist, and retrieves the UEFIOS whitelist. Then, upon receiving the boot path information input by the customer (e.g., the whitelist name and boot path), the system checks whether the input conforms to pre-set boot path specification rules. If it does not conform, a warning is output, reminding the customer that the path is not compliant, and the system returns, waiting for the customer to input a new whitelist name and boot path. If the input conforms, the system iterates through the UEFIOS whitelist obtained from the FV Base Addresses and checks if the input whitelist name and boot path are pre-stored. If the comparison confirms that the input whitelist name and boot path are pre-stored, a prompt is output, and the system returns, waiting for the customer to input a new whitelist name and boot path.

[0116] If, after comparison, it is determined that the whitelist name and boot path entered by the customer are not pre-stored, the boot path is loaded and an attempt is made to add the boot path and other information to the UEFIOS whitelist. Specifically, it is determined whether FV size1 can still accommodate the newly added UEFIOS whitelist. If it can, the whitelist is updated and the action ends. If it cannot, a prompt is output indicating that the existing whitelist in the FV space needs to be deleted, and the existing whitelist is deleted. After deletion, the attempt to add the boot path and other information to the UEFIOS whitelist is made again. Furthermore, the deletion action can also be performed based on customer instructions. For example, if a customer instruction to delete an existing whitelist is received, the corresponding action is executed; if no such instruction is received, no action is taken and the process ends directly.

[0117] The boot path whitelist update method provided in this application offers a flexible and reliable way to update the UEFI OS boot path whitelist. The boot path can be stored in the Firmware Volume space, and boot entries can be modified, deleted, or added using the change UEFIOSwhitelist tool. This increases user freedom and flexibility, reduces the workload of R&D investment, lowers the complexity of maintaining the UEFIOS whitelist, significantly reduces BIOS firmware version maintenance costs, avoids frequent releases and testing, and improves the scalability and manageability of system boot entries.

[0118] It should be emphasized that this application is not limited to the UEFIOS whitelist stored in the FV space. It can also perform corresponding file modification, addition, deletion and other actions for other needs that require access to and modification of the FV space. This application does not impose any restrictions.

[0119] The second embodiment of this application relates to a startup path whitelist update device, such as... Figure 10 As shown, it includes:

[0120] Update the startup path acquisition module 201 to obtain the startup path information to be updated;

[0121] The whitelist comparison module 202 is used to compare the startup path information to be updated with a pre-set whitelist list to obtain the whitelist comparison result. The whitelist list includes multiple startup path information in the pre-set startup path whitelist.

[0122] The list update module 203 is used to update the platform configuration database variable based on the startup path information to be updated when the whitelist comparison result is that the startup path information to be updated is different from multiple startup path information in the startup path whitelist, so as to obtain the whitelist list update result. The whitelist list is assigned to the platform configuration database variable.

[0123] The first whitelist update module 204 is used to package the firmware file corresponding to the whitelist update result to obtain the first whitelist update result.

[0124] Based on the above embodiments, the startup path whitelist update device provided in this application further includes:

[0125] The whitelist access module is used to locate and access the firmware volume space through a pre-set volume base address to obtain the whitelist.

[0126] Based on the above implementation, the boot path whitelist is pre-stored in the firmware volume space of the basic input / output system. The whitelist includes a whitelist name list and a whitelist boot path list. The boot path whitelist updating device provided in this application further includes:

[0127] The first variable setting module is used to set the first platform configuration database variable in the firmware volume space of the basic input / output system. The first platform configuration database variable is used to store the whitelist name list.

[0128] The second variable setting module is used to set the second platform configuration database variable in the firmware volume space of the basic input / output system. The second platform configuration database variable is used to store the whitelist boot path list.

[0129] The first variable assignment module is used to assign values ​​to the first platform configuration database variables based on the whitelist name list in the startup path whitelist, and obtain the assigned first platform configuration database variables.

[0130] The second variable assignment module is used to assign values ​​to the second platform configuration database variables based on the whitelist of startup paths in the startup path whitelist, thus obtaining the assigned values ​​of the second platform configuration database variables.

[0131] Based on the above embodiments, the startup path whitelist update device provided in this application further includes:

[0132] The path specification check module is used to check the startup path information to be updated according to the pre-set startup path specification rules, and obtain the checked startup path information to be updated.

[0133] Based on the above embodiments, the startup path whitelist update device provided in this application further includes:

[0134] The startup mode determination module is used to determine the startup mode of the basic input / output system and obtain the startup mode determination result;

[0135] The startup item count acquisition module is used to perform a startup item traversal action on the first whitelist update result when the startup mode judgment result is the unified extensible firmware interface operating system whitelist, and obtain the number of startup items.

[0136] The boot module is used to boot into the operating system corresponding to the first whitelist update result when the number of startup items is greater than 0.

[0137] Based on the above embodiments, the startup path whitelist update device provided in this application further includes:

[0138] The same prompt message generation module is used to output and display the whitelist comparison result when the whitelist comparison result shows that the startup path information to be updated is the same as the startup path information.

[0139] Based on the above embodiments, the whitelist update module 204 in the startup path whitelist update device provided in this application includes:

[0140] Firmware packaging unit 241 is used to package firmware files to obtain intermediate packaging results;

[0141] Private key signing unit 242 is used to sign the packaged intermediate result with the private key to obtain the first whitelist update result.

[0142] Based on the above embodiments, the startup path whitelist update device provided in this application further includes:

[0143] The space memory judgment module is used to judge the space memory of the firmware volume and obtain the space memory judgment result.

[0144] The whitelist adjustment module is used to delete the boot path whitelist in the firmware volume space and adjust the whitelist update result when the space memory judgment result is insufficient firmware volume space, so as to obtain the adjusted whitelist list.

[0145] The second whitelist update module is used to package the firmware files corresponding to the adjusted whitelist list to obtain the second whitelist update result.

[0146] The third embodiment of this application relates to an electronic device, such as... Figure 11 As shown, it includes:

[0147] At least one processor 301; and,

[0148] The memory 302 is communicatively connected to the at least one processor 301; wherein,

[0149] The memory 302 stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor 301 to enable the at least one processor 301 to implement the boot path whitelist update method described in the first embodiment of this application.

[0150] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0151] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0152] The fourth embodiment of this application relates to a non-volatile computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the boot path whitelist update method described in the first embodiment of this application.

[0153] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0154] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0155] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for updating a startup path whitelist, characterized in that, The method includes: Obtain the startup path information to be updated; The startup path information to be updated is compared with a pre-set whitelist to obtain a whitelist comparison result. The whitelist includes multiple startup path information from the pre-set startup path whitelist. When the whitelist comparison result shows that the startup path information to be updated is different from multiple startup path information in the startup path whitelist, the platform configuration database variable is updated according to the startup path information to be updated to obtain the whitelist list update result. The whitelist list is assigned to the platform configuration database variable. The startup path whitelist is pre-stored in the firmware volume space of the basic input / output system. The platform configuration database variable is set in the firmware volume space. The firmware file corresponding to the whitelist update result is packaged to obtain the first whitelist update result.

2. The method according to claim 1, characterized in that, Before comparing the startup path information to be updated with a pre-set whitelist to obtain the whitelist comparison result, the process also includes: The whitelist is obtained by locating and accessing the firmware volume space using the pre-set volume base address.

3. The method according to claim 1, characterized in that, The whitelist includes a whitelist name list and a whitelist startup path list. The platform configuration database variables include a first platform configuration database variable and a second platform configuration database variable. Before comparing the startup path information to be updated with the pre-set whitelist to obtain the whitelist comparison result, the process further includes: The first platform configuration database variable is set in the firmware volume space of the basic input / output system, wherein the first platform configuration database variable is used to store the whitelist name list; The second platform configuration database variable is set in the firmware volume space of the basic input / output system, wherein the second platform configuration database variable is used to store the whitelist boot path list; The whitelist name list in the startup path whitelist is assigned to the first platform configuration database variable to obtain the first platform configuration database variable after assignment. The whitelist of startup paths in the startup path whitelist is assigned to the second platform configuration database variable to obtain the assigned second platform configuration database variable.

4. The method according to claim 1, characterized in that, After obtaining the startup path information to be updated, and before comparing the startup path information to be updated with the whitelist to obtain the whitelist comparison result, the method further includes: The startup path information to be updated is checked according to the pre-set startup path specification rules to obtain the updated startup path information.

5. The method according to claim 3, characterized in that, After packaging the firmware file corresponding to the whitelist update result to obtain the first whitelist update result, the process further includes: The startup mode of the basic input / output system is determined, and the startup mode determination result is obtained. When the startup mode determination result is the unified extensible firmware interface operating system whitelist, a startup item traversal action is performed on the first whitelist update result to obtain the number of startup items; When the number of startup items is greater than 0, the system is booted into the operating system corresponding to the first whitelist update result.

6. The method according to claim 3, characterized in that, The process of packaging the firmware file corresponding to the whitelist update result to obtain the first whitelist update result includes: The firmware file is packaged to obtain an intermediate packaging result; The first whitelist update result is obtained by signing the intermediate packaged result with a private key.

7. The method according to claim 3, characterized in that, When the whitelist comparison result shows that the startup path information to be updated is different from multiple startup path information in the startup path whitelist, after updating the startup path whitelist according to the startup path information to be updated and obtaining the whitelist update result, the method further includes: The firmware volume space is used to determine the memory usage, and the memory usage result is obtained. When the space memory determination result indicates that the firmware volume space is insufficient, the boot path whitelist in the firmware volume space is deleted and the whitelist update result is adjusted to obtain the adjusted whitelist list. The firmware files corresponding to the adjusted whitelist are packaged to obtain the second whitelist update result.

8. A device for updating a startup path whitelist, characterized in that, include: Update the startup path acquisition module to obtain startup path information to be updated; The whitelist comparison module is used to compare the startup path information to be updated with a pre-set whitelist to obtain a whitelist comparison result. The whitelist includes multiple startup path information in the pre-set startup path whitelist. The list update module is used to update the platform configuration database variable according to the startup path information to be updated when the whitelist comparison result shows that the startup path information to be updated is different from multiple startup path information in the startup path whitelist, thereby obtaining a whitelist list update result. The whitelist list is assigned to the platform configuration database variable; the startup path whitelist is pre-stored in the firmware volume space of the basic input / output system; and the platform configuration database variable is set in the firmware volume space. The first whitelist update module is used to package the firmware file corresponding to the whitelist update result to obtain the first whitelist update result.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the boot path whitelist update method as described in any one of claims 1-7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the startup path whitelist update method as described in any one of claims 1-7.

Images