UEFI firmware update methods, devices, equipment and storage media

Abstract

This application discloses a UEFI firmware update method, apparatus, device, and storage medium. The UEFI firmware update method includes: responding to a power-on operation, completing a boot sequence according to the original UEFI firmware, and loading a network driver to establish a network connection; constructing a firmware update request data packet, the firmware update request data packet including the address information and payload data of the computing device; broadcasting the firmware update request data packet within a local area network; obtaining a unicast response packet returned by a firmware management server within the local area network; wherein, the firmware management server generates a unicast response packet according to the payload data in the received firmware update request data packet, and sends the unicast response packet to the computing device according to the address information; and completing the firmware update based on the unicast response packet. This application enables automatic firmware updates via a network.

Description

Technical Field

[0001] This application relates to the field of computer firmware management technology, and in particular to a UEFI firmware update method, apparatus, device and storage medium. Background Technology

[0002] Firmware is the foundational software of hardware devices, such as UEFI (Unified Extensible Firmware Interface) and BIOS (Basic Input / Output System) firmware. It is responsible for tasks such as self-testing, hardware initialization, and booting the operating system of the terminal device. Therefore, it is necessary to check and update the firmware regularly. Its security and version consistency are crucial to the stability and security of the entire system.

[0003] Currently, firmware updates are typically performed manually or via operating system updates. Manual updates are generally performed by maintenance personnel using removable media such as USB drives to manually execute the update program on each device. This method is inefficient, error-prone, and relies on manual operation, making large-scale deployment difficult. Operating system updates, on the other hand, typically involve calling specific tools or drivers to perform the update after the operating system is running. This method heavily depends on the stability and security of the operating system; if the system itself has vulnerabilities or has crashed, the update cannot be performed. Summary of the Invention

[0004] This application aims to provide a UEFI firmware update method, apparatus, device, and storage medium that can automatically complete firmware updates via a network.

[0005] The UEFI firmware update method according to the first aspect of this application, applied to a computing device, includes:

[0006] In response to the power-on operation, the boot sequence is completed according to the original UEFI firmware, and the network driver is loaded to establish a network connection;

[0007] Construct a firmware update request data packet, the firmware update request data packet including the address information and payload data of the computing device;

[0008] The firmware update request data packet is broadcast and sent within the local area network.

[0009] Obtain a unicast response packet returned by the firmware management server within the local area network; wherein, the firmware management server generates the unicast response packet according to the payload data in the received firmware update request data packet, and sends the unicast response packet to the computing device according to the address information;

[0010] The firmware update is completed based on the unicast response packet.

[0011] According to some embodiments of this application, the payload data includes a protocol identifier and device type and firmware version information of the computing device;

[0012] The firmware management server generates the unicast response packet based on the address information and payload data in the received firmware update request data packet, including:

[0013] Obtain the firmware update request data packet;

[0014] Parse the firmware update request data packet to obtain the protocol identifier, the device type, and the firmware version information;

[0015] If the protocol identifier indicates that the firmware update request data packet is valid, the firmware policy database is queried to determine whether there is a new firmware image file for the updated version corresponding to the device type, based on the device type and the firmware version information, and the query result is obtained.

[0016] Based on the query results, the unicast response packet is generated.

[0017] According to some embodiments of this application, generating the unicast response packet based on the query result includes:

[0018] If the query result indicates that the new firmware image file exists in the policy database, an update instruction is generated;

[0019] Obtain the download address information and firmware verification information of the new firmware image file;

[0020] The unicast response packet is generated based on the update instruction information, the download address information, and the firmware verification information.

[0021] According to some embodiments of this application, the step of completing the firmware update based on the unicast response packet includes:

[0022] Parse the unicast response packet to obtain the download address information and the firmware verification information;

[0023] Based on the download address information, establish a network connection with the firmware management server and download the new firmware image file;

[0024] The new firmware image file is verified based on the firmware verification information.

[0025] If the new firmware image file passes verification, the new firmware image file is flashed to complete the firmware update.

[0026] According to some embodiments of this application, the firmware verification information includes a first hash value and a signature file of the new firmware image file, wherein the signature file is obtained by signing the first hash value with a private key; the original UEFI firmware has a pre-installed trusted public key for verifying the signature file;

[0027] The step of verifying the new firmware image file based on the firmware verification information includes:

[0028] The signature file is verified using the trusted public key to obtain the verification result.

[0029] If the signature verification result indicates that the signature verification is successful, the signature file is designed to obtain a second hash value;

[0030] The downloaded new firmware image file is hashed to obtain a third hash value;

[0031] If the first hash value, the second hash value, and the third hash value are consistent, the new firmware image file verification is successful.

[0032] According to some embodiments of this application, the step of flashing the new firmware image file to complete the firmware update includes:

[0033] Back up the original UEFI firmware to the backup storage area;

[0034] The new firmware image file is flashed to the main firmware storage area to obtain the new UEFI firmware;

[0035] Perform a cold reboot, complete the boot sequence according to the new UEFI firmware, and complete the firmware update.

[0036] According to some embodiments of this application, generating the unicast response packet based on the query result includes:

[0037] If the query result indicates that the new firmware image file does not exist in the policy database, a no-update instruction message is generated;

[0038] The unicast response packet is generated based on the no-update instruction information.

[0039] According to a second aspect embodiment of this application, the UEFI firmware update apparatus includes:

[0040] The startup module is used to respond to the power-on operation, complete the startup sequence according to the original UEFI firmware, and load the network driver to establish a network connection;

[0041] The construction module is used to construct a firmware update request data packet, which includes the address information and payload data of the computing device;

[0042] The sending module is used to broadcast the firmware update request data packet within the local area network;

[0043] The acquisition module is used to acquire a unicast response packet returned by the firmware management server in the local area network; wherein, the firmware management server generates the unicast response packet according to the payload data in the received firmware update request data packet, and sends the unicast response packet to the computing device according to the address information;

[0044] The update module is used to complete the firmware update based on the unicast response packet.

[0045] An electronic device according to a third aspect of this application includes 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 UEFI firmware update method as described in any of the first aspects of the present application.

[0046] A computer-readable storage medium according to a fourth aspect embodiment of the present application stores computer-executable instructions for performing the UEFI firmware update method as described in the first aspect embodiment above.

[0047] In this embodiment, when the computing device boots normally according to the original UEFI firmware, it simultaneously establishes a network connection by loading a network driver and broadcasts a firmware update request data packet within the local area network (LAN) to send the update request. The firmware management server within the LAN remains in a listening state. Upon receiving a request, it internally searches for a suitable new firmware to update the computing device and replies with a unicast response packet. The computing device can then complete the firmware update based on the received unicast response packet. In this application, during the UEFI boot phase, a new firmware version can be automatically found and discovered within the LAN, enabling automatic UEFI firmware updates without manual intervention or reliance on the operating system. This significantly improves the efficiency and timeliness of updates, thereby achieving networked and automated firmware management and effectively enhancing operational efficiency.

[0048] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. Attached Figure Description

[0049] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0050] Figure 1 This is a flowchart illustrating an embodiment of the UEFI firmware update method of this application;

[0051] Figure 2 This is a schematic diagram of an embodiment of the UEFI firmware update device of this application;

[0052] Figure 3 This is a schematic diagram of the hardware structure of an embodiment of the electronic device of this application. Detailed Implementation

[0053] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0054] In the description of this application, the use of terms such as "first," "second," etc., is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or the order of the technical features indicated.

[0055] In the description of this application, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0056] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0057] The technical solution of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are some embodiments of this application, not all embodiments.

[0058] Figure 1 A flowchart illustrating the UEFI firmware update method provided in this application; Figure 2 This is a schematic diagram of an embodiment of the UEFI firmware update device of this application; Figure 3 This is a schematic diagram of the hardware structure of an embodiment of the electronic device of this application.

[0059] See below. Figure 1 The embodiments of this application will be further described below.

[0060] This application provides a UEFI firmware update method applied to a computing device, which includes the following steps:

[0061] Step 101: In response to the power-on operation, complete the boot sequence according to the original UEFI firmware and load the network driver to establish a network connection;

[0062] Step 102: Construct a firmware update request data packet, which includes the address information and payload data of the computing device;

[0063] Step 103: Broadcast and send firmware update request data packets within the local area network;

[0064] Step 104: Obtain the unicast response packet returned by the firmware management server in the local area network; wherein, the firmware management server generates a unicast response packet according to the payload data in the received firmware update request data packet, and sends the unicast response packet to the computing device according to the address information.

[0065] Step 105: Complete the firmware update based on the unicast response packet.

[0066] In this embodiment, when the computing device boots normally according to the original UEFI firmware, it simultaneously establishes a network connection by loading a network driver and broadcasts a firmware update request data packet within the local area network (LAN) to send the update request. The firmware management server within the LAN remains in a listening state. Upon receiving a request, it internally searches for a suitable new firmware to update the computing device and replies with a unicast response packet. The computing device can then complete the firmware update based on the received unicast response packet. In this application, during the UEFI boot phase, a new firmware version can be automatically found and discovered within the LAN, enabling automatic UEFI firmware updates without manual intervention or reliance on the operating system. This significantly improves the efficiency and timeliness of updates, thereby achieving networked and automated firmware management and effectively enhancing operational efficiency.

[0067] The aforementioned computing devices can be devices with computing capabilities, or more specifically, domestically produced computing platforms such as the Phytium platform, or computers based on domestic CPUs such as Phytium.

[0068] The above response to power-on operation involves completing the boot sequence based on the original UEFI firmware and loading the network driver to establish a network connection. This occurs in the very early stages after the computing device powers on, before the operating system has started. The entire process happens below the operating system level and is a completely independent action performed by the device during its power-on self-test (POST). It does not rely on any operating system such as Windows or Linux. Even if the operating system crashes, is infected with a virus, or the hard drive is removed, this update process can still be executed. The entire process is automatically triggered without manual intervention, such as inserting a USB drive or entering commands. Utilizing the lowest-level UEFI environment during the computer's boot process, the device is awakened, performs self-checks, connects to the network, and prepares to execute subsequent tasks the instant it powers on.

[0069] Specifically, this process is described using the Phytium platform as an example. First, the Phytium platform is powered on, and the CPU boots from the ROM, executing the original UEFI firmware code. That is, after pressing the power button, the CPU reads the first line of instructions from a hardware-inherent read-only memory chip ROM and begins execution. The program stored in the ROM is the UEFI firmware, which is responsible for detecting whether the core hardware such as the CPU and memory is functioning properly. Second, the UEFI driver execution sequence, namely the DXE stage, loads the network driver and device driver. After the core hardware self-test is completed, the UEFI enters the DXE (Driver Execution Environment) stage, initializing more hardware and enabling the operation of modules such as network cards and hard drives through simple drivers. Subsequently, a lightweight network protocol stack is loaded, namely the lightweight network driver integrated into the original UEFI firmware, which supports common network protocols such as TFTP and HTTP. This network protocol stack provides the device with basic network communication capabilities, enabling it to communicate with the firmware update server via a local area network even without operating system support. Finally, the Phytium platform establishes a network connection and joins the local area network.

[0070] The aforementioned lightweight network driver must use a network protocol stack compliant with UEFI specifications to ensure compatibility across different device environments. Because the UEFI environment is very streamlined, its network driver is much simpler than the driver in the operating system, yet sufficient to complete basic network communication tasks. The lightweight network driver supports IPv4, UDP, TFTP, HTTP BAS, and HTTPS protocols. HTTPS requires a TLS encryption stack to ensure the security of the download process. The lightweight network driver obtains an IP address via DHCP (Dynamic Host Configuration Protocol). If this fails, it falls back to a pre-configured static IP address. In some cases, the automatic update module is called, with the entry function being FirmwareUpdateMain(). That is, once the necessary hardware, especially the network card, is ready, the UEFI firmware will execute the designed automatic update function, automatically connecting to the network and automatically obtaining the new firmware to complete the update.

[0071] The aforementioned firmware update request data packet includes the address information and payload data of the computing device. The computing device constructs the firmware update request data packet to send a firmware update request. The firmware update request data packet includes the address information and payload data of the computing device. The address information is the network address information of the computing device itself, and the payload data includes the device model and the currently used firmware version of the computing device, and may also include verification information.

[0072] The above-mentioned method of broadcasting firmware update request data packets within a local area network (LAN) eliminates the need for the local computing device, meaning the client needs to know the server's precise IP address beforehand. This greatly simplifies network configuration and enables the device to automatically discover firmware update servers within the LAN. In some cases, multicast can also be used.

[0073] For example, the client constructs a discovery_request structure in memory:

[0074] #pragma pack(1) / / Byte alignment

[0075] typedef struct {

[0076] uint32_tmagic; / / Magic word, for example, 0x11223344

[0077] uint8_tuuid

[16] ; / / Device-unique UUID

[0078] charmodel

[16] ; / / Device model string, such as "FT-D2000"

[0079] char current_ver

[12] ; / / Current firmware version string, such as "2.0.0"

[0080] uint32_tclient_ip; / / Client's IP address (network byte order)

[0081] } discovery_request_t;

[0082] #pragma pack()

[0083] The address information is the client's IP address, and the payload data contains a fixed magic number (MagicNumber) to identify this protocol, as well as key information such as device model, current firmware version number, and device UUID.

[0084] When broadcasting a firmware update request data packet, the source address is set to the computing device's own MAC address and IP address, and the destination address is set to the broadcast address (e.g., 255.255.255.255) and port 8888. The client module sends this firmware update request data packet to the preset service discovery port via the UDP protocol. In some cases, a retransmission timer can be started, such as setting a 3-second timer. If no response is received within the timeout period, the broadcast is resent, and a maximum number of retries is set, such as a maximum of 3 retries. If all retries fail, an error log is recorded and the update process is exited, continuing to boot normally using the original UEFI firmware.

[0085] In some implementations, the payload data includes a protocol identifier and information about the computing device's device type and firmware version.

[0086] The firmware management server generates a unicast response packet based on the address information and payload data in the received firmware update request data packet, including:

[0087] Obtain the firmware update request data packet;

[0088] Parse the firmware update request data packet to obtain the protocol identifier, device type, and firmware version information;

[0089] If the protocol identifier indicates that the firmware update request data packet is valid, the firmware policy database is queried to determine whether there is a new firmware image file for the corresponding device type based on the device type and firmware version information, and the query results are obtained.

[0090] Generate a unicast response packet based on the query results.

[0091] In this embodiment, a firmware management server is deployed within the local area network where the computing device is located. The firmware management server stores various versions of firmware. When a firmware update request data packet is received, it can determine whether it can provide the updated firmware required by the computing device based on the specific information, and generate a unicast response packet to send back to the computing device via unicast.

[0092] The above protocol identifier can be a magic word.

[0093] Specifically, a daemon process runs on the firmware management server deployed within the local area network. This process continuously listens to the aforementioned service discovery port, port 8888. When the server captures a firmware update request data packet broadcast by a computing device, it first parses the magic word to confirm that it is a legitimate firmware discovery request. Subsequently, the server parses information such as the device model and current version in the firmware update request data packet and queries its firmware policy database to determine whether there is a firmware image with an updated version suitable for that device model. In some cases, the policy database includes more complex rules, such as setting a time window to only allow updates to be distributed between 2:00 AM and 4:00 AM; setting forced updates, where a certain version must be forcibly updated due to security vulnerabilities; and setting batch updates, updating 10% of devices first, observing for a period of time without problems before rolling out to the whole network.

[0094] In some implementations, a unicast response packet is generated based on the query results, including:

[0095] If the query results indicate that a new firmware image file exists in the policy database, an update instruction message is generated.

[0096] Obtain the download address information and firmware verification information of the new firmware image file;

[0097] Based on the update instruction information, download address information, and firmware verification information, a unicast response packet is generated.

[0098] In this embodiment, the firmware management server generates a corresponding unicast response packet based on the query results of an internal search to see if there is a suitable new firmware that matches the computing device for updating. If the query results indicate that a new firmware image file exists in the policy database, an instruction can be issued to instruct the computing device to update and provide relevant information about the new firmware.

[0099] Specifically, if the query results indicate the existence of a new firmware image file in the policy database, the firmware management server generates a unicast response packet and sends it directly back to the client's IP address. The unicast response packet should include: update instruction information, explicitly indicating that an update is needed; download address information for the new firmware image file, such as the client calling the corresponding UEFI protocol (EFI_TFTP_PROTOCOL) based on the URL protocol type (e.g., tftp: / / ); and firmware verification information for the new firmware image file, which can be metadata about the new firmware, including the new version number, file size, digital signature, and hash value of the firmware image. The digital signature is used to verify the authenticity of the firmware, and the hash value of the firmware image, such as SHA-256, is used to verify the integrity of the firmware file. In some cases, the server only returns the latest version information, and the client compares the version number locally and decides whether an update is needed.

[0100] In some implementations, the firmware update is completed based on the unicast response packet, including:

[0101] Parse the unicast response packet to obtain the download address information and firmware verification information;

[0102] Based on the download address information, establish a network connection with the firmware management server and download the new firmware image file;

[0103] The new firmware image file is verified based on the firmware verification information.

[0104] If the new firmware image file passes verification, flash the new firmware image file to complete the firmware update.

[0105] In this embodiment, the computing device obtains a unicast response packet returned by the firmware management server within the local area network, and then parses it to obtain the download address information and firmware verification information of the new firmware image file. The download address information allows for network download, and the firmware verification information allows for security verification, ensuring that the downloaded new firmware image file is safe and reliable. The firmware update is only completed using the new firmware image file if the security verification is successful, thus improving the security of the firmware update process.

[0106] Specifically, after receiving the unicast response from the server, the client parses the information within it and, based on the URL in the response packet, establishes a connection with the server using the HTTP or TFTP protocol supported in the UEFI environment, and begins downloading the firmware image file. Understandably, before downloading, it checks whether there is enough space in the local Flash storage. The download process supports resuming interrupted downloads to ensure reliable completion even when the network is unstable.

[0107] In some implementations, during the preparation phase, for new firmware, operations personnel calculate its hash value, sign it using the company's private key to obtain a signature file, and place the signature file in a designated directory on the firmware management server. Additionally, a new record is added to the firmware management server's policy database, and discovery and file services are started.

[0108] For example, the operations and maintenance personnel generate a SHA-256 hash value HASH_new for the new firmware FW_v2.1.bin. They then sign HASH_new using the company's private key to generate a signature file FW_v2.1.sig, which is placed in a specified directory on the server.

[0109] Specifically, the maintenance personnel first perform a hash value calculation based on the SHA-256 algorithm on the new firmware file FW_v2.1.bin to generate a unique, fixed-length code, namely the hash value HASH_new, which can be regarded as the digital fingerprint of the file. If the file content changes, this fingerprint will be completely different. The hash value can verify the integrity of the file, that is, whether the file has been damaged or tampered with during transmission after its release.

[0110] Then, the maintenance personnel use the company's strictly confidential private key to sign this HASH_new, i.e., encrypt it. This encryption produces a digital signature (.sig file). After the computing device obtains the signature file from the firmware management server, it can use its built-in public key to verify and design the signature file, i.e., decrypt it. The signature can verify the authenticity of the file, i.e., that the firmware comes from a legitimate company, because only the company has the private key to sign.

[0111] Starting the discovery service and file service involves launching two server-side programs. The discovery service constantly monitors the network for devices broadcasting update requests, while the file service handles the sending of files when a device needs to download them.

[0112] This preparation phase is the safety cornerstone of the entire automation process, ensuring that all subsequent automation steps are carried out under a trustworthy and controllable premise. After the maintenance personnel complete the preparation work in this phase, the computing devices, such as Phytium devices, can automatically and safely complete the batch updates.

[0113] In some implementations, the firmware verification information includes a first hash value of the new firmware image file and a signature file, wherein the signature file is obtained by signing the first hash value with a private key; the original UEFI firmware has a pre-installed trusted public key for verifying the signature file.

[0114] The new firmware image file is verified based on the firmware verification information, including:

[0115] The signature file is verified using a trusted public key to obtain the verification result.

[0116] If the signature verification result indicates that the signature verification is successful, the signature file is designed to obtain the second hash value;

[0117] The hash value of the downloaded new firmware image file is calculated to obtain the third hash value;

[0118] If the first, second, and third hash values ​​are consistent, the new firmware image file verification is successful.

[0119] In this implementation, the authenticity and integrity of the new firmware image file are verified based on firmware verification information. Authenticity verification is achieved by verifying the signature file using a trusted public key. If the verification passes, the firmware source is considered genuine and legitimate; if it fails, the firmware source is considered untrustworthy or has been modified, and the process is terminated. If the verification result indicates success, the signature file is designed to obtain a second hash value, and the downloaded new firmware image file is hashed to obtain a third hash value. The first, second, and third hash values ​​are compared. If they match, the firmware file is considered complete; if they do not match, the file has been corrupted or tampered with during the download process, and the process is terminated. This triple hash value comparison verification effectively ensures security.

[0120] In some implementations, flashing a new firmware image file completes the firmware update, including:

[0121] Back up the original UEFI firmware to the backup storage area;

[0122] The new firmware image file is flashed to the main firmware storage area to obtain the new UEFI firmware;

[0123] Perform a cold reboot, complete the boot sequence according to the new UEFI firmware, and complete the firmware update.

[0124] In this implementation, the client module first backs up the device's current firmware to a backup storage area, which can be a specific, non-volatile storage area, such as another partition of Flash memory, to prepare for rollback in case the new firmware update fails. Then, it calls the UEFI firmware flashing interface, such as Flash Protocol, to securely write the verified new firmware image to the main firmware storage area. After flashing is complete, the device automatically performs a cold reboot (ColdReboot). After rebooting, the UEFI code boots from the updated main firmware partition to ensure the new firmware is fully effective.

[0125] In some cases, upon re-entering the UEFI phase after a reboot, the client module will again execute the boot sequence based on the UEFI firmware, load the network driver, and establish a network connection. It will then send a broadcast request to the server, containing the updated version number. Upon receiving this request, the server will find the version number is now up-to-date and record the successful update status in the log database, completing the entire closed-loop process. If the update fails and the version number remains unchanged, the server can trigger an alarm mechanism.

[0126] In some implementations, a unicast response packet is generated based on the query results, including:

[0127] If the query results indicate that no new firmware image file exists in the policy database, a no-update instruction message is generated.

[0128] Generate a unicast response packet based on the absence of update instructions.

[0129] In this embodiment, the firmware management server generates a corresponding unicast response packet based on the query results of whether there is a suitable new firmware to update the computing device. If the query results indicate that no new firmware image file exists in the policy database, an instruction can be issued instructing the computing device not to update. In some cases, the firmware management server may also choose to ignore the request and not respond.

[0130] In some implementations, this application enables proactive discovery and device-side proactive broadcasting, reducing server configuration complexity and providing strong network adaptability. It prioritizes security by employing a dual security mechanism of hash verification and digital signatures to ensure the firmware's reliable origin and complete content, fundamentally preventing malicious firmware flashing. It achieves an automated closed loop, from discovery, download, verification, and update to final status confirmation, requiring no manual intervention throughout the entire process, forming a complete automated closed loop. It is compatible with domestic applications, as the entire solution is deeply integrated into the Phytium platform's UEFI environment, independent of any operating system, achieving the lowest-level, OS-independent firmware management capabilities.

[0131] The UEFI firmware update method provided in this application can be executed by a UEFI firmware update device 200. This application uses the UEFI firmware update device 200 executing the UEFI firmware update method as an example to illustrate the UEFI firmware update device 200 provided in this application.

[0132] Please see Figure 2 This is a schematic diagram of the structure of a UEFI firmware update device 200 provided in an embodiment of this application. Figure 2 As shown, the UEFI firmware update device 200 includes:

[0133] The startup module 201 is used to respond to the power-on operation, complete the startup sequence according to the original UEFI firmware, and load the network driver to establish a network connection;

[0134] Module 202 is used to construct a firmware update request data packet, which includes the address information and payload data of the computing device;

[0135] The sending module 203 is used to broadcast firmware update request data packets within the local area network;

[0136] The acquisition module 204 is used to acquire the unicast response packet returned by the firmware management server in the local area network; wherein, the firmware management server generates a unicast response packet according to the payload data in the received firmware update request data packet, and sends the unicast response packet to the computing device according to the address information.

[0137] Update module 205 is used to complete the firmware update based on the unicast response packet.

[0138] In some implementations, the payload data includes a protocol identifier and information about the computing device's device type and firmware version.

[0139] Module 204 can be used for:

[0140] Obtain the firmware update request data packet;

[0141] Parse the firmware update request data packet to obtain the protocol identifier, device type, and firmware version information;

[0142] If the protocol identifier indicates that the firmware update request data packet is valid, the firmware policy database is queried to determine whether there is a new firmware image file for the corresponding device type based on the device type and firmware version information, and the query results are obtained.

[0143] Generate a unicast response packet based on the query results.

[0144] In some implementations, the acquisition module 204 can be used to:

[0145] If the query results indicate that a new firmware image file exists in the policy database, an update instruction message is generated.

[0146] Obtain the download address information and firmware verification information of the new firmware image file;

[0147] Based on the update instruction information, download address information, and firmware verification information, a unicast response packet is generated.

[0148] In some implementations, the update module 205 can be used to:

[0149] Parse the unicast response packet to obtain the download address information and firmware verification information;

[0150] Based on the download address information, establish a network connection with the firmware management server and download the new firmware image file;

[0151] The new firmware image file is verified based on the firmware verification information.

[0152] If the new firmware image file passes verification, flash the new firmware image file to complete the firmware update.

[0153] In some implementations, the firmware verification information includes a first hash value of the new firmware image file and a signature file, wherein the signature file is obtained by signing the first hash value with a private key; the original UEFI firmware has a pre-installed trusted public key for verifying the signature file.

[0154] Update module 205, which can be used for:

[0155] The signature file is verified using a trusted public key to obtain the verification result.

[0156] If the signature verification result indicates that the signature verification is successful, the signature file is designed to obtain the second hash value;

[0157] The hash value of the downloaded new firmware image file is calculated to obtain the third hash value;

[0158] If the first, second, and third hash values ​​are consistent, the new firmware image file verification is successful.

[0159] In some implementations, the update module 205 can be used to:

[0160] Back up the original UEFI firmware to the backup storage area;

[0161] The new firmware image file is flashed to the main firmware storage area to obtain the new UEFI firmware;

[0162] Perform a cold reboot, complete the boot sequence according to the new UEFI firmware, and complete the firmware update.

[0163] In some implementations, the acquisition module 204 can be used to:

[0164] If the query results indicate that no new firmware image file exists in the policy database, a no-update instruction message is generated.

[0165] Generate a unicast response packet based on the absence of update instructions.

[0166] Since the UEFI firmware update device 200 adopts all the technical solutions of the UEFI firmware update method of the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, and will not be described in detail here.

[0167] Figure 3 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0168] This electronic device may include a processor 301 and a memory 302 storing computer program instructions.

[0169] Specifically, the processor 301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0170] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 302 may include removable or non-removable (or fixed) media. Where appropriate, memory 302 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 302 is non-volatile solid-state memory.

[0171] In some embodiments, memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0172] The processor 301 implements any of the UEFI firmware update methods described in the above embodiments by reading and executing computer program instructions stored in the memory 302.

[0173] In one example, the electronic device may also include a communication interface 303 and a bus 310. For example, Figure 3As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 310 and complete communication with each other.

[0174] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0175] Bus 310 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0176] The electronic device can execute the UEFI firmware update method in the embodiments of this application, thereby achieving the combination Figure 1 and Figure 2 The UEFI firmware update method and apparatus described herein.

[0177] Furthermore, in conjunction with the UEFI firmware update methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the UEFI firmware update methods in the above embodiments.

[0178] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0179] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0180] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0181] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0182] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A UEFI firmware update method, characterized in that, Applied to a computing device, comprising: in response to power-on operation, completing a start sequence according to original UEFI firmware, and loading a network driver to establish a network connection; constructing a firmware update request data packet, the firmware update request data packet comprising address information of the computing device and payload data; broadcasting the firmware update request data packet in a local area network; obtaining a unicast response packet returned by a firmware management server in the local area network; wherein the firmware management server generates the unicast response packet according to the payload data in the firmware update request data packet broadcasted by the computing device, and sends the unicast response packet to the computing device according to the address information; completing firmware update according to the unicast response packet.

2. The UEFI firmware update method of claim 1, wherein, the payload data comprises a protocol identifier, a device type of the computing device, and firmware version information; the firmware management server generates the unicast response packet according to the address information and the payload data in the received firmware update request data packet, comprising: obtaining the firmware update request data packet; parsing the firmware update request data packet to obtain the protocol identifier, the device type, and the firmware version information; in the case where the protocol identifier indicates that the firmware update request data packet is legal, querying a firmware policy database to determine whether there is a new firmware image file corresponding to the updated version of the device type according to the device type and the firmware version information, and obtaining a query result; generating the unicast response packet according to the query result.

3. The UEFI firmware update method of claim 2, wherein, the generating the unicast response packet according to the query result, comprising: in the case where the query result indicates that the new firmware image file exists in the policy database, generating update instruction information; obtaining download address information and firmware verification information of the new firmware image file; generating the unicast response packet according to the update instruction information, the download address information, and the firmware verification information.

4. The UEFI firmware update method of claim 3, wherein, the completing firmware update according to the unicast response packet, comprising: parsing the unicast response packet to obtain the download address information and the firmware verification information; establishing a network connection with the firmware management server according to the download address information, and downloading the new firmware image file; verifying the new firmware image file according to the firmware verification information; in the case where the new firmware image file passes the verification, flashing the new firmware image file to complete firmware update.

5. The UEFI firmware update method of claim 4, wherein, the firmware verification information comprises a first hash value of the new firmware image file and a signature file, the signature file being obtained by signing the first hash value with a private key; a trusted public key for verifying the signature file is pre-stored in the original UEFI firmware; the verifying the new firmware image file according to the firmware verification information, comprising: verifying the signature file with the trusted public key to obtain a verification result; in the case where the verification result indicates that the verification passes, obtaining a second hash value by un-signing the signature file; calculating a third hash value of the downloaded new firmware image file; In a case where the first hash value, the second hash value and the third hash value are consistent, the new firmware image file is verified.

6. The UEFI firmware update method of claim 4, wherein, The new firmware image file is written to complete firmware update, including: Backup the original UEFI firmware to a backup storage area; Write the new firmware image file to the main firmware storage area to obtain a new UEFI firmware; Perform a cold restart, complete a startup sequence according to the new UEFI firmware, and complete firmware update.

7. The UEFI firmware update method of claim 2, wherein, The unicast response packet is generated according to the query result, including: In a case where the query result indicates that the new firmware image file does not exist in the policy database, generate no update instruction information; Generate the unicast response packet according to the no update instruction information.

8. A UEFI firmware update apparatus, characterized by, Including: A starting module is configured to complete a startup sequence according to an original UEFI firmware and load a network driver to establish a network connection in response to a power-on operation; A building module is configured to build a firmware update request data packet, the firmware update request data packet including address information and payload data of a computing device; A sending module is configured to broadcast the firmware update request data packet in a local area network; An obtaining module is configured to obtain a unicast response packet returned by a firmware management server in the local area network; wherein the firmware management server generates the unicast response packet according to the payload data in the received firmware update request data packet, and sends the unicast response packet to the computing device according to the address information; An updating module is configured to complete firmware update according to the unicast response packet.

9. An electronic device, comprising: The computer readable storage medium stores computer executable instructions for causing a computer to execute the UEFI firmware update method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer executable instructions for causing a computer to execute the UEFI firmware update method according to any one of claims 1 to 7.

Images