Pre-authorized virtualization engine for dynamic firmware measurement

A virtual BIOS engine may be configured to, during runtime of an operating system, in response to an operating system event for updating firmware, load onto an isolated compute domain of the processor to emulate firmware update processes of a non-transitory computer-readable media with a virtual non-transitory computer-readable media and emulate the firmware update processes of the cryptoprocessor with a virtual cryptoprocessor, extract a firmware payload to the virtual non-transitory computer-readable media, and execute a virtual trust chain to measure the firmware payload in the virtual non-transitory computer-readable media.

TECHNICAL FIELD

The present disclosure relates in general to information handling systems, and more particularly to methods and systems for enabling a pre-authorized virtualization engine for dynamic firmware measurement, for use in performing a firmware update.

BACKGROUND

A critical component of modern information handling systems is the basic input/output system (BIOS). A BIOS may comprise boot firmware configured to be the first code executed by a processor of an information handling system when the information handling system is booted and/or powered on, and serves to initialize information handling resources of the information handling system and/or initialize interoperation of the information handling system with other information handling systems.

Due to its critical role in booting an information handling system and configuring various components of the information handling system for use, it is critical that an installed BIOS be a known, secure version of the BIOS, in order to reduce or eliminate potential for malicious attack.

One way to establish trust in BIOS and other firmware is a Root of Trust for Measurement (RTM), in which each firmware component is measured, and such measurement is verified prior to firmware execution. Creating an RTM involves building a trust chain when the information handling system boots, such that each firmware module is measured by the previous firmware module and extended into an event log of a cryptoprocessor of the information handling system (e.g., into a platform configuration register (PCR) of a trusted platform module (TPM)) prior to receiving control of host computing resources. A sequence and set of required measurements may be defined in a firmware profile for the cryptoprocessor, wherein a trust chain may begin at the first piece of BIOS code to execute (e.g., a Core Root of Trust for Measurement) and may end at the transition to an operating system bootloader. Attestation of the firmware measurements collected by an RTM may provide the foundation for assurance that firmware is secure.

Under traditional approaches, firmware updates within an operating system environment require a reboot into a pre-boot firmware environment to re-establish the trust chain for the RTM. After performing this reboot, the measurements of the new firmware result in a new RTM state, which may be attested or verified to re-establish trust in the information handling system. If the new RTM state resulting from the new firmware measurement in the trust chain is determined to be untrusted, the new firmware must be reverted to the “last known good” firmware by rebooting and re-flashing the firmware, causing further interruptions to productivity. In other words, no mechanism exists for calculating firmware measurements with a hash extended into the cryptoprocessor event log, without first performing a reboot.

SUMMARY

In accordance with the teachings of the present disclosure, the disadvantages and problems associated with measurement of firmware updates may be reduced or eliminated.

In accordance with embodiments of the present disclosure, an information handling system may include a processor, first non-transitory computer-readable media communicatively coupled to the processor and having stored thereon a basic input/output system (BIOS), a cryptoprocessor, and second non-transitory computer-readable media communicatively coupled to the processor and having stored thereon an operating system and a virtual BIOS engine. The virtual BIOS engine may be configured to, during runtime of the operating system, in response to an operating system event for updating firmware, load onto an isolated compute domain of the processor to emulate firmware update processes of the first non-transitory computer-readable media with a virtual non-transitory computer-readable media and emulate the firmware update processes of the cryptoprocessor with a virtual cryptoprocessor, extract a firmware payload to the virtual non-transitory computer-readable media, and execute a virtual trust chain to measure the firmware payload in the virtual non-transitory computer-readable media.

In accordance with embodiments of the present disclosure, a method may be provided for use in an information handling system having a processor, first non-transitory computer-readable media communicatively coupled to the processor and having stored thereon a basic input/output system (BIOS), a cryptoprocessor, and second non-transitory computer-readable media communicatively coupled to the processor and having stored thereon an operating system. The method may include executing a virtual BIOS engine configured to, during runtime of the operating system, in response to an operating system event for updating firmware, load onto an isolated compute domain of the processor to emulate firmware update processes of the first non-transitory computer-readable media with a virtual non-transitory computer-readable media and emulate the firmware update processes of the cryptoprocessor with a virtual cryptoprocessor, extract a firmware payload to the virtual non-transitory computer-readable media, and execute a virtual trust chain to measure the firmware payload in the virtual non-transitory computer-readable media.

In accordance with embodiments of the present disclosure, an article of manufacture may include a first non-transitory computer-readable medium having stored thereon an operating system and computer-executable instructions carried on the first computer-readable medium, the instructions readable by a processor. The instructions may be configured to, when read and executed, cause the processor to, in an information handling system having a processor, the first non-transitory computer-readable media communicatively coupled to the processor, second non-transitory computer-readable media communicatively coupled to the processors and having stored thereon a basic input/output system (BIOS), and a cryptoprocessor, execute a virtual BIOS engine during runtime of the operating system. The virtual BIOS engine may be configured to, in response to an operating system event for updating firmware, load onto an isolated compute domain of the processor to emulate firmware update processes of the second non-transitory computer-readable media with a virtual non-transitory computer-readable media and emulate the firmware update processes of the cryptoprocessor with a virtual cryptoprocessor, extract a firmware payload to the virtual non-transitory computer-readable media, and execute a virtual trust chain to measure the firmware payload in the virtual non-transitory computer-readable media.

DETAILED DESCRIPTION

Preferred embodiments and their advantages are best understood by reference toFIGS.1through4, wherein like numbers are used to indicate like and corresponding parts.

FIG.1illustrates a block diagram of an example information handling system102, in accordance with embodiments of the present disclosure. In some embodiments, an information handling system102may comprise a personal computer. In some embodiments, an information handling system102may comprise or be an integral part of a server. In other embodiments, an information handling system102may comprise a portable information handling system (e.g., a laptop or notebook, etc.). As depicted inFIG.1, an information handling system102may include a processor103, a memory104communicatively coupled to processor103, a Serial Peripheral Interface (SPI) flash105communicatively coupled to processor103, and a cryptoprocessor108communicatively coupled to processor103.

Operating system106may comprise any program of executable instructions, or aggregation of programs of executable instructions, configured to manage and/or control the allocation and usage of hardware resources such as memory, processor time, disk space, and input and output devices, and provide an interface between such hardware resources and application programs hosted by operating system106. In addition, operating system106may include all or a portion of a network stack for network communication via a network interface. Active portions of operating system106may be transferred to memory104for execution by processor103. Although operating system106is shown inFIG.1as stored in memory104, in some embodiments, operating system106may be stored in storage media accessible to processor103, and active portions of operating system106may be transferred from such storage media to memory104for execution by processor103.

Virtual BIOS engine110may comprise any program of executable instructions, or aggregation of programs of executable instructions, configured to execute on top of operating system106in order implement an isolated virtual engine environment for staging and firmware measurement protocol (IVSFM) to measure firmware prior to update to synchronize such measurement with an event log of cryptoprocessor108for dynamic validation of the measurement by cryptoprocessor108. For example, virtual BIOS engine110may dynamically measure, during operating system runtime, a firmware payload prior to update and tag measurement identifiers to cryptoprocessor108for the actual update. In addition, virtual BIOS engine110may be configured to execute in an isolated firmware measurement compute environment, such as an isolated hybrid processing core of processor103, to emulate SPI flash105and cryptoprocessor108for purposes of evaluating the firmware update. Further, virtual BIOS engine110may dynamically compare and evaluate configuration parameters of BIOS firmware112and operating system106to ensure no power-on/self-test (POST) errors occurred in the boot path to operating system106, as well as retaining and/or updating configuration settings.

SPI flash105may include any system, device, or apparatus configured to store BIOS firmware112. As used herein, a BIOS may include any system, device, or apparatus configured to identify, test, and/or initialize information handling resources of information handling system102, and/or initialize interoperation of information handling system102with other information handling systems. “BIOS” may broadly refer to any system, device, or apparatus configured to perform such functionality, including without limitation, a Unified Extensible Firmware Interface (UEFI). In some embodiments, a BIOS may be implemented as a program of instructions that may be read by and executed on processor103to carry out the functionality of the BIOS. In these and other embodiments, the BIOS may comprise boot firmware configured to be the first code executed by processor103when information handling system102is booted and/or powered on. As part of its initialization functionality, code for the BIOS may be configured to set components of information handling system102into a known state, so that one or more applications (e.g., an operating system or other application programs) stored on compatible media (e.g., disk drives) may be executed by processor103and given control of information handling system102.

Cryptoprocessor108may be communicatively coupled to processor103(e.g., via a suitable communication bus) and may include any system, device, or apparatus configured to carry out cryptographic operations on data communicated to it from processor103and/or another component of information handling system102. In some embodiments, cryptoprocessor108may be compliant with the Trusted Platform Module specification, a successor specification, and/or any other similar specification. In some embodiments, cryptoprocessor108may be configured to generate random numbers, generate encryption keys (e.g., RSA keys), generate and maintain hash key tables of hardware and software components of information handling system102, generate and maintain configuration parameters associated with hardware and software components of an information handling system, wrap (e.g., encrypt) keys, unwrap (e.g., decrypt) keys, and/or store keys (e.g., endorsement key, storage root key, attestation identity keys, storage keys).

As shown inFIG.1, cryptoprocessor108may include configuration registers114. In some embodiments, configuration registers114may include platform configuration registers (PCRs) compliant with the Trusted Platform Module specification, a successor specification, and/or any other similar specification. Configuration registers114may be used to securely store any relevant information, including without limitation secure storage relating to measurements of a configuration of information handling system102and its components, for use in creating a secure chain of trust.

In addition to processor103, memory104, SPI flash105, and cryptoprocessor108, information handling system102may include one or more other information handling resources.

FIG.2illustrates a functional block diagram of virtual BIOS engine110and its interaction with other components of information handling system102, in accordance with embodiments of the present disclosure. As shown inFIG.2, in response to a firmware update being triggered (e.g., by an event occurring within operating system106), virtual BIOS engine110may load on an isolated compute domain created on a hybrid processing core of processor103, with permissions for secure access to resources of operating system106. Once loaded, virtual BIOS engine110may execute in such isolated compute domain, and may perform staging and verification of a firmware payload by measuring the firmware code in a virtual SPI flash204instantiated in a secure storage namespace202, such that virtual SPI flash204acts as a virtual RTM. Thus, while operating system106may continue to use cryptoprocessor108(e.g., via cryptoprocessor configuration access module210), virtual BIOS engine110may extend measurement records into a virtual cryptoprocessor event queue206and may pass virtual cryptoprocessor event queue206to cryptoprocessor108during a subsequent boot session after firmware update. This virtual RTM may be attested (e.g., locally or remotely) prior to performing an actual physical reboot. Such attestation is beyond the scope of this disclosure.

As shown inFIG.2, storage namespace202may also include a configuration space208for storing configuration settings that may be required to be retained and updated in order to ensure boot success with old against new configuration defaults.

In operation, in response to the firmware update trigger, a firmware update event manager212of virtual BIOS engine110may load and execute firmware measurement protocol214. Firmware measurement protocol214may extract a firmware payload representing a firmware update into virtual SPI flash and perform a firmware measurement as a virtual RTM, establishing a virtual trust chain. Virtual cryptoprocessor event queue206may store all measurement signature identifiers for the firmware update processor to access during platform boot with the newly-updated firmware image. Thus, virtual BIOS engine110may implement a virtual cryptoprocessor to execute an application programming interface of cryptoprocessor108and the security protocol of cryptoprocessor108required for measurements.

FIG.3illustrates a flow chart of an example method300for attesting new firmware, in accordance with embodiments of the present disclosure. According to one embodiment, method300may begin at step302. As noted above, teachings of the present disclosure may be implemented in a variety of configurations of information handling system102.

At step302, operating system106may attempt to execute a firmware update. At step304, the firmware update event may trigger a sequence that loads virtual BIOS engine110onto an isolated compute domain on a hybrid processing core of processor103, in order to emulate the firmware update processes.

At step306, the emulated environment of virtual BIOS engine110may execute firmware measurement protocol214and extract the firmware payload into virtual SPI flash204.

At step308, firmware measurement protocol214may perform a virtual trust chain to measure the image of the firmware payload in virtual SPI flash204. For example, by emulating a virtual cryptoprocessor, firmware measurement protocol214may compute hashes of each firmware volume and extend each firmware volume hash to a configuration register114(e.g., PCR 0). Firmware measurement protocol214may then perform a quote of such configuration register (e.g., using a cryptographic key created for such purpose, which is beyond the scope of this disclosure), and verify a signature of the quote with the cryptographic key. Firmware measurement protocol214may also attest the final state of the virtual RTM, to verify the new emulated RTM state, and verify a digest from the quote against a digest provided with the firmware update. If attestation and verification are successful, firmware measurement protocol214may write the pending firmware payload image to SPI flash105.

AlthoughFIG.3discloses a particular number of steps to be taken with respect to method300, method300may be executed with greater or fewer steps than those depicted inFIG.3. In addition, althoughFIG.3discloses a certain order of steps to be taken with respect to method300, the steps comprising method300may be completed in any suitable order.

Method300may be implemented using information handling system102or any other system operable to implement method300. In certain embodiments, method300may be implemented partially or fully in software and/or firmware embodied in computer-readable media.

FIG.4illustrates a flow chart of an example method400for extending new firmware and old firmware together in a cryptoprocessor108to attest a firmware update process, in accordance with embodiments of the present disclosure. According to one embodiment, method400may begin at step402. As noted above, teachings of the present disclosure may be implemented in a variety of configurations of information handling system102.

At step402, operating system106may attempt to execute a firmware update. At step404, virtual BIOS engine110may perform the attestation process for the new firmware, as described with respect to method300above.

At step406, if the attestation process for the new firmware is successful, firmware measurement protocol214may request a pause of accesses by operating system106to cryptoprocessor108, in order to prevent collisions between accesses by operating system106and accessing by virtual BIOS engine110. For example, firmware measurement protocol214may call an operating system runtime service to lock the cryptoprocessor108for operating system access to cryptoprocessor108while firmware measurement protocol214is using cryptoprocessor108. At step408, firmware measurement protocol214may extend the new firmware payload into cryptoprocessor108while cryptoprocessor108is locked from access by operating system106.

At step410, firmware measurement protocol214may perform a quote of a configuration register114(e.g., PCR 0). At this point, such configuration register may include a digest of the old firmware image and the new firmware image.

At step412, a verifier (e.g., a remote verifier coupled to a network interface of information handling system102) may compare a quote of configuration registers114performed during step404/method300to a digest of a firmware hash of the old firmware image, to ensure that the new firmware image will be installed over the correct old firmware image.

At step414, a verifier (e.g., a remote verifier coupled to a network interface of information handling system102) may verify the signature of the quote performed at step410. For example, the verifier may calculate a hash of a concatenation of a digest from step404/method300and a hash of the new firmware image, and compare such hash to the quote performed at step410.

At step416, if the verifications of steps412and414are successful, firmware measurement protocol214may release control of cryptoprocessor108from virtual BIOS engine110back to operating system106, and commit the new firmware image to SPI flash105.

At step418, at a subsequent boot of information handling system102, a verifier may issue a cryptoprocessor quote command and compare the quote to the newly-updated event log to confirm that the new firmware image is committed in SPI flash105.

AlthoughFIG.4discloses a particular number of steps to be taken with respect to method400, method400may be executed with greater or fewer steps than those depicted inFIG.4. In addition, althoughFIG.4discloses a certain order of steps to be taken with respect to method400, the steps comprising method400may be completed in any suitable order.

Method400may be implemented using information handling system102or any other system operable to implement method400. In certain embodiments, method400may be implemented partially or fully in software and/or firmware embodied in computer-readable media.