Unified extensible firmware interface (UEFI) capsule-based update of firmware logo image

A firmware is configured with a firmware management protocol (“FMP”) capable of updating a firmware logo image and a firmware logo image volume is defined within a firmware for storing a firmware logo image. A firmware logo image updater executing on a computing device receives a UEFI capsule that contains a firmware logo image. The firmware logo image updater stores the UEFI capsule in a UEFI system partition on a computer-readable storage medium accessible to the computing device. Upon a reboot of the computing device, the FMP is executed. The FMP retrieves the UEFI capsule from the UEFI system partition. The FMP then updates the firmware logo image volume with the firmware logo image stored in the UEFI capsule.

BACKGROUND

Many types of computing devices display an image, or images, at boot time. For example, firmware executing on a computing device might display an on-screen image, or images, when the computing device is powered on or rebooted that identifies the manufacturer of the computing device or the developer of the firmware. These images are commonly referred to as “firmware logo images.”

Original equipment manufacturers (“OEMs”) of computing devices commonly obtain motherboards from original design manufacturers (“ODMs”) and create computing devices based on the motherboards. One of the main modifications that OEMs make to ODM-manufactured motherboards is to replace the firmware logo image in the firmware installed on the motherboards by the ODMs with an OEM-specific firmware logo image.

One method for modifying the firmware of a computing device to include an OEM-specific firmware logo image involves building a custom firmware that includes the OEM-specific firmware logo image for the OEM. Creating custom firmware for many OEMs can, however, be a difficult and time consuming process.

Another method for modifying the firmware of a computing device to include an OEM-specific firmware logo image involves utilizing custom software tools that require that the firmware be re-cryptographically signed. Re-signing firmware may, however, interfere with security updates to a computing device.

The two methods identified above for modifying the firmware of a computing device to include an OEM-specific firmware logo image also require the entire firmware to be re-flashed (i.e., programmed into a non-volatile memory device). Re-flashing an entire firmware may, however, result in a firmware becoming corrupted such as, for example, in the event of power loss during the firmware update. Corrupted firmware can cause a computing device to be unable to boot.

It is with respect to these and other technical considerations that the disclosure made herein is presented.

SUMMARY

Technologies are described herein for UEFI capsule-based updating of a firmware logo image. Through implementations of the disclosed technologies, the firmware logo image of a computing device can be updated without re-flashing an entire firmware. Implementations of the disclosed technologies can also update a firmware logo image in a secure manner that prevents a computing device from becoming unable to boot in the event of power loss during update of the firmware logo image. Technical benefits other than those specifically mentioned herein can also be realized through implementations of the disclosed technologies.

In order to provide these technical benefits, and potentially others, a computing device is provided that includes a firmware that implements aspects of the disclosed technologies. In an embodiment, for instance, the firmware is a Unified Extensible Firmware Interface (“UEFI”) Specification-compliant firmware that has been configured with a firmware management protocol (“FMP”) capable of updating a firmware logo image, which may be referred to herein as the “logo update FMP.” Additionally, a separate region, referred to herein as the “firmware logo image volume,” is defined within the firmware for storing a firmware logo image. The firmware logo image volume is signed or hashed separately from the remainder of the firmware and, therefore, modifications to the contents of the firmware logo image volume will not result in the need to re-cryptographically sign the entire firmware.

In an embodiment, a firmware logo image updater executing on a computing device receives a UEFI capsule that contains a firmware logo image. For example, in an embodiment, the firmware logo image updater receives the UEFI capsule from a firmware update server. The firmware logo image updater receives the UEFI capsule from other sources in other embodiments.

In an embodiment, the UEFI capsule includes a globally unique identifier (“GUID”) in addition to the firmware logo image. In this embodiment, the firmware logo image updater is configured to authenticate the contents of the UEFI capsule based on the specified GUID.

The firmware logo image updater stores the UEFI capsule in a UEFI system partition on a computer-readable storage medium accessible to the computing device. Upon a reboot of the computing device, the logo update FMP is executed. The logo update FMP retrieves the UEFI capsule from the UEFI system partition. The logo update FMP then updates the firmware logo image volume with the firmware logo image stored in the UEFI capsule.

It should be appreciated that the above-described subject matter can also be implemented as a computer-controlled apparatus, a computer process, a computing system or device, or as an article of manufacture such as a computer-readable storage medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.

DETAILED DESCRIPTION

The following detailed description is directed to technologies for UEFI capsule-based updating of a firmware logo image. As discussed briefly above, implementations of the disclosed technologies enable the firmware logo image of a computing device to be updated without re-flashing an entire firmware. Implementations of the disclosed technologies can also update a firmware logo image in a secure manner that prevents a computing device from becoming unable to boot in the event of power loss during update of the firmware logo image. Technical benefits other than those specifically mentioned herein can also be realized through implementations of the disclosed technologies.

Those skilled in the art will also appreciate that aspects of the subject matter described herein can be practiced on or in conjunction with other computer system and device configurations beyond those described herein, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, handheld computers, personal digital assistants, e-readers, mobile telephone devices, tablet computing devices, special-purposed hardware devices, network appliances, and the like. The configurations described herein can be practiced in distributed computing environments, where tasks can be performed by remote computing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and that show, by way of illustration, specific configurations or examples. The drawings provided herewith are not drawn to scale. Like numerals represent like elements throughout the several figures (which might be referred to herein as a “FIG.” or “FIGS.”).

FIG.1is a computing device architecture diagram showing aspects of one mechanism disclosed herein for UEFI capsule-based updating of a firmware logo image. As described briefly above, many types of computing devices display an image, or images, at boot time. For example, firmware executing on a computing device, such as the computing device104shown inFIG.1, might display an on-screen image, or images, when the computing device is powered on or rebooted that identifies the manufacturer of the computing device, the developer of the firmware, or provides other information. These images are commonly referred to as “firmware logo images.”

As also discussed briefly above, OEMs of computing devices commonly obtain motherboards from ODMs and create computing devices based on the motherboards. One of the main modifications that OEMs make to ODM-manufactured motherboards is to replace the firmware logo image in the firmware installed on the motherboards by the ODMs with an OEM-specific firmware logo image.

One method for modifying the firmware of a computing device to include an OEM-specific firmware logo image involves building a custom firmware that includes the OEM-specific firmware logo image for the OEM. Creating custom firmware for many OEMs can, however, be a difficult and time consuming process.

Another method for modifying the firmware of a computing device to include an OEM-specific firmware logo image involves utilizing custom software tools that require that the firmware be re-cryptographically signed. Re-signing firmware may, however, interfere with security updates to a computing device.

The two methods identified above for modifying the firmware of a computing device to include an OEM-specific firmware logo image also require the entire firmware to be re-flashed (i.e., programmed into a non-volatile memory device). Re-flashing an entire firmware may, however, result in a firmware becoming corrupted such as, for example, in the event of power loss during the firmware update. Corrupted firmware can cause a computing device to be unable to boot.

In order to address the technical considerations set forth above, and potentially others, a computing device104is provided that includes a firmware106that implements aspects of the disclosed technologies. In an embodiment, for instance, the firmware106is a UEFI Specification-compliant firmware. Additional details regarding the configuration and operation of a UEFI Specification-compliant firmware will be provided below with regard toFIG.3.

As shown inFIG.1, the firmware106is configured with a FMP128(which may be referred to herein as the “logo update FMP128”) capable of updating a firmware logo image102. As discussed briefly above, the firmware106executing on the computing device104can display the firmware logo image102when the computing device104is powered on or rebooted. The firmware logo image102can identify the manufacturer of the computing device104, the developer of the firmware106, or provide other information to a user of the computing device104.

A separate region, referred to herein as the “firmware logo image volume126D,” is defined within the firmware106for storing a firmware logo image102. The firmware logo image volume126D is cryptographically signed or hashed separately from the remainder of the firmware106and, therefore, modifications to the contents of the firmware logo image volume126D will not result in the need to re-cryptographically sign the entire firmware106. In contrast, modifications to the contents of the boot block firmware volume126A, the non-volatile random access memory (“NVRAM”) firmware volume126B, or the main firmware volume126C would require that the entire firmware106be re-cryptographically signed.

In an embodiment, a firmware logo image updater122executes on an operating system124executing on the computing device104. The firmware logo image updater122is a software component configured to retrieve a UEFI capsule110that contains a firmware logo image102. A UEFI capsule is a data structure defined by the UEFI Specification for use in transferring firmware update information from the operating system124to the firmware106.

In an embodiment, another computing device108is utilized to create the UEFI capsule110. The computing device108can then be utilized to provide the UEFI capsule110to the firmware logo image updater122. In an embodiment, the computing device108provides the UEFI capsule110to a firmware update server112. The firmware logo image updater122retrieves the UEFI capsule110from the firmware update server112. The firmware logo image updater122receives the UEFI capsule110from other sources in other embodiments. For example, the firmware logo image updater122can retrieve the UEFI capsule110from a mass storage device or another type of computer-readable storage medium in other embodiments.

As shown inFIG.1, the UEFI capsule110includes a UEFI capsule payload116that includes a firmware image118containing the firmware logo image102. The UEFI capsule110also includes a UEFI capsule header114. In an embodiment, the UEFI capsule header114stores a globally unique identifier (“GUID”) (not shown inFIG.1). In this embodiment, the firmware logo image updater122is configured to authenticate the contents of the UEFI capsule110based on the specified GUID. For instance, the firmware logo image updater122can determine based on the GUID whether the computing device104supports the UEFI capsule110. If the computing device104does not support the UEFI capsule110, the operations described below for updating the firmware logo image102will not be performed.

In an embodiment, the firmware logo image updater122stores the UEFI capsule110in a UEFI system partition316(shown inFIG.3) on a computer-readable storage medium accessible to the computing device104. Upon a reboot of the computing device104, the logo update FMP128is executed. The logo update FMP128retrieves the UEFI capsule110from the UEFI system partition316. The logo update FMP128then updates the firmware logo image volume126D with the firmware logo image102stored in the UEFI capsule110. Additional details regarding this process will be provided below with respect toFIG.2.

FIG.2is a flow diagram showing a routine200that illustrates aspects of the operation of the mechanism shown inFIG.1for UEFI capsule-based updating of a firmware logo image102, according to one embodiment presented herein. It is to be appreciated that the logical operations described herein with respect toFIG.2and the other FIGS., can be implemented (1) as a sequence of computer implemented acts or program modules running on a computing device and/or (2) as interconnected machine logic circuits or circuit modules within the computing device.

The implementation of the various components described herein is a matter of choice dependent on the performance and other requirements of the computing device. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules can be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations might be performed than shown in the FIGS. and described herein. These operations can also be performed in parallel, or in a different order than those described herein. These operations can also be performed by components other than those specifically identified.

The routine200begins at operation202, where the computing device108can be utilized to create a UEFI capsule110that is formatted in the manner shown inFIG.1and that includes a firmware logo image102for the computing device104. The routine200then proceeds from operation202to operation204, where the computing device108provides the UEFI capsule110to the firmware update server112in an embodiment.

From operation204, the routine200proceeds to operation206, where the firmware logo image updater122retrieves the UEFI capsule110from the firmware update server112. The routine200then proceeds from operation206to operation208, where the firmware logo image updater122stores the UEFI capsule110in the UEFI system partition316(shown inFIG.3). The computing device104is then rebooted at operation210.

From operation210, the routine200proceeds to operation212, where the computing device104executes the logo update FMP128to update the firmware logo image stored in the firmware logo image volume126D with the firmware logo image102contained in the UEFI capsule110. Subsequently, at operation214, the firmware106can display the firmware logo image102on a display screen connected to the computing device104when the computing device is powered on or rebooted. From operation214, the routine200proceeds to operation216, where it ends.

Turning now toFIG.3, a software architecture diagram will be described that illustrates an architecture300for a UEFI Specification-compliant firmware that can be configured to provide and/or utilize aspects of the technologies disclosed herein. In particular, the firmware architecture300shown inFIG.3can be utilized to implement the firmware106described above. The firmware106can also be implemented in other ways in other configurations.

The UEFI Specification describes an interface between an OS124and a UEFI Specification-compliant firmware106. The UEFI Specification also defines an interface that a firmware106can implement, and an interface that an OS124can use while booting. How a firmware implements the interface can be left up to the manufacturer of the firmware106. The UEFI Specification also defines a way for an OS124and a firmware106to exchange information necessary to support the operating system boot process. The term “UEFI Specification” used herein refers to the EFI Specification developed by INTEL CORPORATION, the UEFI Specification managed by the UEFI FORUM, and other related specifications available from the UEFI FORUM.

As shown inFIG.3, the architecture can include platform hardware320, such as that described below with regard toFIG.4, an OS124, and a UEFI system partition316. The UEFI system partition316can be an architecturally shareable system partition. As such, the UEFI system partition316can define a partition and file system designed to support safe sharing of mass storage between multiple vendors. An OS partition318can also be utilized to store the OS124.

Once started, the UEFI OS loader304can continue to boot the complete OS124. In doing so, the UEFI OS loader304can use UEFI boot services306, UEFI runtime services308, and an interface to other supported specifications, to survey, comprehend, and initialize the various platform components and the OS software that manages them. Thus, interfaces314from other specifications can also be present on the system. For example, the Advanced Configuration and Power Management Interface (“ACPI”) and the System Management BIOS (“SMBIOS”) specifications can be supported.

UEFI boot services306can provide interfaces for devices and system functionality used during boot time. UEFI runtime services308can also be available to the UEFI OS loader304during the boot phase and can provide interfaces, such as the services described above. UEFI allows extension of platform specific firmware310by loading UEFI driver and UEFI application images (not shown inFIG.3) which, when loaded, have access to UEFI-defined runtime and boot services such as those described above.

Additional details regarding the operation and architecture of a UEFI Specification-compliant firmware can be found in the UEFI Specification, which is available from the UEFI Forum. The UEFI Forum has also provided further details regarding recommended implementation of UEFI in the form of the Platform Initialization (“PI”) Specification. Unlike the UEFI Specification, which focuses on programmatic interfaces for the interactions between the OS124and system firmware106, the PI specification describes a firmware implementation that has been designed to perform the full range of operations that are required to initialize a platform from power on through transfer of control to the OS124. The PI specification, which is available from UEFI Forum, is also expressly incorporated herein by reference.

Referring now toFIG.4, a computer architecture diagram that shows an illustrative architecture for a computer that can provide an operating environment for the technologies presented herein will be described. For example, and without limitation, the computer architecture shown inFIG.4can be utilized to implement a computing device104that executes the firmware106.

FIG.4and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the configurations described herein can be implemented. While the technical details are presented herein in the general context of program modules that execute in conjunction with the execution of an operating system, those skilled in the art will recognize that the configurations can also be implemented in combination with other program modules.

Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the configurations described herein can be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The configurations described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

In particular,FIG.4shows an illustrative computer architecture for a computer400that can implement the technologies described herein. The illustrative computer architecture shown inFIG.4includes a baseboard, or “motherboard”, which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication path. In one illustrative configuration, a central processing unit (“CPU”)402operates in conjunction with a Platform Controller Hub (“PCH”)406. The CPU402is a central processor that performs arithmetic and logical operations necessary for the operation of the computer400. The computer400can include a multitude of CPUs402. Each CPU402might include multiple processing cores.

The CPU402provides an interface to a RAM used as the main memory424in the computer400and, possibly, to an on-board graphics adapter410. The PCH406provides an interface between the CPU402and the remainder of the computer400.

The PCH406can also be responsible for controlling many of the input/output functions of the computer400. In particular, the PCH406can provide one or more universal serial bus (“USB”) ports412, an audio codec422, an Ethernet controller430, and one or more general purpose input/output (“GPIO”) pins414. The USB ports412can include USB 2.0 ports, USB 3.0 ports and USB 3.1 ports among other USB ports.

The PCH406can also include functionality for providing networking functionality through an Ethernet controller430. The Ethernet controller430is capable of connecting the computer400to another computer via a network. Connections that can be made by the Ethernet controller430can include LAN or WAN connections. LAN and WAN networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

The PCH406can also provide a bus for interfacing peripheral card devices such as a graphics adapter432. In one configuration, the bus comprises a PCI bus. The PCI bus can include a Peripheral Component Interconnect (“PCI”) bus, a Peripheral Component Interconnect extended (“PCI-X”) bus and a Peripheral Component Interconnect Express (“PCIe”) bus among others.

The PCH406can also provide a system management bus434for use in managing the various components of the computer400. Additional details regarding the operation of the system management bus434and its connected components are provided below. Power management circuitry426and clock generation circuitry428can also be utilized during the operation of the PCH406.

The PCH406is also configured to provide one or more interfaces for connecting mass storage devices to the computer400. For instance, according to one configuration, the PCH406includes a serial advanced technology attachment (“SATA”) adapter for providing one or more serial ATA ports416. The serial ATA ports416can be connected to one or more mass storage devices storing an OS, such as OS124and application programs420, such as a SATA disk drive418. As known to those skilled in the art, an OS124comprises a set of programs that control operations of a computer and allocation of resources. An application420is software that runs on top of the OS124, or other runtime environment, and uses computer resources to perform application specific tasks desired by the user, such as those described herein.

According to one configuration, the OS124comprises the LINUX operating system. According to another configuration, the OS124comprises the WINDOWS operating system from MICROSOFT CORPORATION. According to another configuration, the OS124comprises the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized.

The mass storage devices connected to the PCH406, and their associated computer-readable storage media, provide non-volatile storage for the computer400. Although the description of computer-readable storage media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable storage media can be any available media that can be accessed by the computer400.

By way of example, and not limitation, computer-readable storage media can comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. However, computer-readable storage media does not encompass transitory signals. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information, and which can be accessed by the computer400.

A low pin count (“LPC”) interface can also be provided by the PCH406for connecting a Super I/O device408. The Super I/O device408is responsible for providing a number of input/output ports, including a keyboard port, a mouse port, a serial interface, a parallel port, and other types of input/output ports. The LPC interface can also connect a computer storage media such as a ROM or a flash memory such as a non-volatile memory442for storing firmware106that includes program code containing the basic routines that help to start up the computer400and to transfer information between elements within the computer400as discussed above.

It should be appreciated that the program modules disclosed herein, including the firmware106, can include software instructions that, when loaded into the CPU402and executed, transform a general-purpose computer400into a special-purpose computer400customized to facilitate all, or part of, the operations disclosed herein. As detailed throughout this description, the program modules can provide various tools or techniques by which the computer400can participate within the overall systems or operating environments using the components, logic flows, and/or data structures discussed herein.

The CPU402can be constructed from any number of transistors or other circuit elements, which can individually or collectively assume any number of states. More specifically, the CPU402can operate as a state machine or finite-state machine. Such a machine can be transformed to a second machine, or a specific machine, by loading executable instructions contained within the program modules.

These computer-executable instructions can transform the CPU402by specifying how the CPU402transitions between states, thereby transforming the transistors or other circuit elements constituting the CPU402from a first machine to a second machine, wherein the second machine can be specifically configured to perform the operations disclosed herein. The states of either machine can also be transformed by receiving input from one or more user input devices, network interfaces (such as the Ethernet controller430), other peripherals, other interfaces, or one or more users or other actors. Either machine can also transform states, or various physical characteristics of various output devices such as printers, speakers, video displays, or otherwise.

Encoding the program modules can also transform the physical structure of the storage media. The specific transformation of physical structure can depend on various factors, in different implementations of this description. Examples of such factors can include but are not limited to the technology used to implement the storage media, whether the storage media are characterized as primary or secondary storage, and the like. For example, if the storage media are implemented as semiconductor-based memory, the program modules can transform the physical state of the semiconductor main memory424and/or non-volatile memory442. For example, the software can transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory.

As another example, the storage media can be implemented using magnetic or optical technology such as hard drives or optical drives. In such implementations, the program modules can transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations can include altering the magnetic characteristics of particular locations within given magnetic media. These transformations can also include altering the physical features or characteristics of particular locations within given optical media to change the optical characteristics of those locations. It should be appreciated that various other transformations of physical media are possible without departing from the scope and spirit of the present description.

As described above, the PCH406can include a system management bus434. The system management bus434can include a baseboard management controller (“BMC”)440. The BMC440is a microcontroller that monitors operation of the computer400. The BMC440monitors health-related aspects associated with the computer400, such as, but not limited to, the temperature of one or more components of the computer400, speed of rotational components (e.g., spindle motor, CPU fan, etc.) within the computer400, the voltage across or applied to one or more components within the computer400, and the available and/or used capacity of memory devices within the computer400. To accomplish these monitoring functions, the BMC440is communicatively connected to one or more components by way of the system management bus434in some configurations.

In one configuration, these components include sensor devices438for measuring various operating and performance-related parameters within the computer400. The sensor devices438can be either hardware or software based components configured or programmed to measure or detect one or more of the various operating and performance-related parameters.

The BMC440functions as the master on the system management bus434in most circumstances but can also function as either a master or a slave in other circumstances. Each of the various components communicatively connected to the BMC440by way of the system management bus434is addressed using a slave address. The system management bus434is used by the BMC440to request and/or receive various operating and performance-related parameters from one or more components, such as the firmware106, which are also communicatively connected to the system management bus434.

It should be appreciated that the functionality provided by the computer400can be provided by other types of computing devices, including hand-held computers, smartphones, gaming systems, set top boxes, tablet computers, embedded computer systems, personal digital assistants, and other types of computing devices known to those skilled in the art. It is also contemplated that the computer400might not include all the components shown inFIG.4, can include other components that are not explicitly shown inFIG.4, or might utilize an architecture completely different than that shown inFIG.4.

Based on the foregoing, it should be appreciated that technologies for UEFI capsule-based updating of a firmware logo image have been disclosed herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological acts, and computer readable media, it is to be understood that the present invention is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts and mediums are disclosed as example forms.