Securely loading UEFI images at runtime

• US 10,726,133 B1
• Filed: 02/04/2019
• Issued: 07/28/2020
• Est. Priority Date: 02/04/2019
• Status: Active Grant

• Current Assignee: Dell Products LP (Dell Technologies Inc.)
• Original Assignee: Dell Products LP (Dell Technologies Inc.)
• Inventors: Vidyadhara, Sumanth, Joshi, Anand Prakash
• Primary Examiner(s): Choudhury, Zahid
• Application Number:
  US16/267,277
• Publication Number:
  US 20200250314A1
• Time in Patent Office: 540 Days
• CPC Class Codes: G06F 16/901 Indexing; Data structures therefor; Storage structures for retrieval from the web G06F16/951
• CPC Class Codes: G06F 21/572 Secure firmware programming, e.g. of basic input output system [BIOS]
• CPC Class Codes: G06F 21/575 Secure boot
• CPC Class Codes: G06F 8/654 using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
• CPC Class Codes: G06F 9/4411 Configuring for operating with peripheral devices; Loading of device drivers

Abstract

UEFI images can be securely loaded at runtime so that it is unnecessary to flash the entire platform firmware whenever a UEFI image is added or updated. The platform firmware can include an OEM file list that maps file GUIDs to public keys. When it is desired to add a UEFI image, the OEM can employ one of the file GUIDs in the OEM file list and a private key corresponding to the mapped public key to create the UEFI image. During the PEI phase of the boot process, a verification module in the platform firmware can verify any added UEFI image using the OEM file list. Additionally, to ensure that the added UEFI images will pass the subsequent Secure Boot verification, a sync module can add custom Secure Boot keys for the added UEFI images to the Secure Boot databases during the DXE phase of the boot process.

Claims

1. A method for securely loading Unified Extensible Firmware Interface (UEFI) images at runtime, the method comprising:

installing platform firmware on a computing device, the platform firmware including a Secure Boot database, a verification module and a file list that defines mappings between file globally unique identifiers (GUIDs) and public keys, the mappings including a first mapping between a first file GUID and a first public key;

after the platform firmware has been installed on the computing device, creating a first UEFI image by assigning the first file GUID to the first UEFI image and including a first signature of the first UEFI image that is generated using a first private key that corresponds to the first public key;

storing the first UEFI image with the first signature on the computing device;

during a subsequent boot process, identifying, by the verification module, that the first UEFI image has been stored on the computing device;

employing, by the verification module, the first public key to verify the first signature; and

in response to the verification module verifying the first signature, adding the first signature to the Secure Boot database to thereby cause the first UEFI module to be verified during Secure Boot verification.

2. The method of claim 1, wherein the first UEFI image is a first driver execution environment (DXE) module.

3. The method of claim 2, wherein the first signature is added to the Secure Boot database by a second DXE module that is configured to be executed prior to the first DXE module.

4. The method of claim 1, wherein storing the first UEFI image with the first signature on the computing device comprises storing the first UEFI image in a firmware volume on a reserved partition of a hard disk or in Serial Peripheral Interface (SPI) flash.

5. The method of claim 1, wherein identifying, by the verification module, that the first UEFI image has been stored on the computing device comprises accessing the file list to determine that the first file GUID is defined in the file list and determining that the first UEFI image has been assigned the first file GUID.

6. The method of claim 1, wherein employing, by the verification module, the first public key to verify the first signature includes determining, based on the first mapping, that the first public key should be used to verify the first signature.

7. The method of claim 1, wherein the first UEFI image is a DXE driver.

8. The method of claim 1, wherein the mappings include a second mapping between a second file GUID and a second public key, the method further comprising:

creating a second UEFI image by assigning the second file GUID to the second UEFI image and including a second signature of the second UEFI image that is generated using a second private key that corresponds to the second public key;

storing the second UEFI image with the second signature on the computing device;

during a subsequent boot process, identifying, by the verification module, that the first and second UEFI images have been stored on the computing device;

employing, by the verification module, the first public key to verify the first signature and the second public key to verify the second signature; and

in response to the verification module verifying the first and second signatures, adding the first and second signatures to the Secure Boot database to thereby cause the first and second UEFI modules to be verified during Secure Boot verification.

9. The method of claim 1, wherein the verification module employs the first public key to verify the first signature during a pre-EFI initialization (PEI) phase of the boot process and a DXE module that executes during a DXE phase of the boot process adds the first signature to the Secure Boot database.

10. A method for securely loading Unified Extensible Firmware Interface (UEFI) images at runtime, the method comprising:

during a boot process, accessing, by a verification module that is part of platform firmware on a computing device, a file list that is also part of the platform firmware, the file list defining mappings between file globally unique identifiers (GUIDs) and public keys;

accessing, by the verification module, one or more firmware volumes stored on the computing device to determine whether any UEFI images in the one or more firmware volumes have a file GUID matching a file GUID defined in the file list;

upon determining that a first UEFI image stored in one of the one or more firmware volumes has a first file GUID that is defined in the file list, employing, by the verification module, a first public key to which the first file GUID is mapped to verify a first signature that is stored with the first UEFI image; and

in response to the verification module verifying the first signature, adding, by a driver execution environment (DXE) module, the first signature to a Secure Boot database that is part of the platform firmware.

11. The method of claim 10, wherein the verification module executes during a pre-EFI initialization (PEI) phase of the boot process and the DXE module executes during a DXE phase of the boot process.

12. The method of claim 10, wherein the one or more firmware volumes are stored in Serial Peripheral Interface (SPI) flash.

13. The method of claim 10, wherein adding the first signature to the Secure Boot database comprises adding a custom Secure Boot key to the Secure Boot database, the custom Secure Boot key corresponding to the first signature.

14. The method of claim 10, wherein the platform firmware that includes the file list is signed using an original equipment manufacturer (OEM) private key and verified using a corresponding public key stored in a central processing unit of the computing device.

15. The method of claim 10, further comprising:

upon determining that a second UEFI image stored in one of the one or more firmware volumes has a second file GUID that is defined in the file list, employing, by the verification module, a second public key to which the second file GUID is mapped to verify a second signature that is stored with the second UEFI image; and

in response to the verification module verifying the second signature, adding, by the DXE module, the second signature to the Secure Boot database.

16. The method of claim 10, wherein the first UEFI image is a DXE driver.

17. A computing device comprising:

a central processing unit (CPU) that stores an original equipment manufacturer (OEM) public key;

flash memory on which platform firmware is stored, the platform firmware being signed with an OEM private key corresponding to the OEM public key, the platform firmware including Secure Boot databases, a verification module and a file list that defines mappings between file globally unique identifiers (GUIDs) and public keys; and

storage on which one or more firmware volumes are stored, the one or more firmware volumes including a first set of UEFI images each of which has a signature that is stored in the Secure Boot databases of the signed platform firmware and a second set of UEFI images each of which has a signature that is not stored in the Secure Boot databases of the signed platform firmware;

wherein the verification module is configured to verify the UEFI images in the second set by determining, for each UEFI image in the second set, whether the UEFI image has a file GUID that is defined in the file list and if so whether the UEFI image was signed using a private key that corresponds to the public key to which the file GUID is mapped.

18. The computing device of claim 17, wherein the first set of UEFI images includes a sync module in the form of a DXE module that is configured to add, to the Secure Boot databases, a signature of each UEFI image in the second set that was verified by the verification module.

19. The computing device of claim 18, wherein the verification module verifies the UEFI images in the second set during a pre-EFI initialization (PEI) phase of a boot process and the sync module adds the signature of each UEFI image in the second set that was verified by the verification module during a DXE phase of the boot process.

20. The computing device of claim 17, wherein the storage comprises one or both of a reserved partition of a hard disk or Serial Peripheral Interface (SPI) flash.