FAULT-TOLERANT VARIABLE REGION REPAVING DURING FIRMWARE OVER THE AIR UPDATE

• US 20180004505A1
• Filed: 12/06/2016
• Published: 01/04/2018
• Est. Priority Date: 06/30/2016
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Inventors: Annapureddy, Thirupathaiah, Mehendale, Bhushan, Mahood, Adam Matthew, Justin, Ajit
• Granted Patent: US 10,140,117 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 11/1433 during software upgrading
• 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 3/0619 in relation to data integrity, e.g. data losses, bit errors
• CPC Class Codes: G06F 3/065 Replication mechanisms
• CPC Class Codes: G06F 3/067 Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
• CPC Class Codes: G06F 3/0688 Non-volatile semiconductor memory arrays
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57
• 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/485 Task life-cycle, e.g. stopping, restarting, resuming execution G06F9/4881 takes precedence
• CPC Class Codes: H04L 67/34 involving the movement of software or configuration parameters network booting or remote initial program loading [RIPL] G06F9/4416

Abstract

Variables utilized in device firmware that provides various boot and runtime services are repaved in a fault-tolerant manner within a secure store in a durable, non-volatile device memory during an FOTA update process. A spare region in the secure store is utilized to temporarily hold a back-up of a primary region in which the firmware variables are written. Using a transaction-based fault-tolerant write (FTW) process, the variables in the primary region can be repaved with variables contained in a firmware update payload that is delivered from a remote service. In the event of a fault in the variable region repaving process, either the primary or spare region will remain valid so that firmware in a known good state can be utilized to enable the device to boot successfully and the variable region repaving in the FOTA update process may be restarted.

Claims

1. A method for updating firmware on a device, comprising:

exposing a secure non-volatile memory store on the device, comprising a primary region and a spare region, each of the primary region and spare region including a working store configured to store transaction records and a variable store configured to store variable records;

copying variable records in the primary region and writing the variable records to the spare region;

erasing content in the working store within the primary region;

erasing variable records in the primary region;

copying variable records from a firmware update payload received at the device and writing the copied variable records into the primary region; and

erasing variable records in the spare region.

2. The method of claim 1 in which the variable records represent UEFI (Unified Extensible Firmware Interface) variables.

3. The method of claim 1 in which the memory store is one of SPI (serial peripheral interface), Flash memory, or eMMC (embedded multimedia card) memory.

4. The method of claim 1 in which each of the writing steps comprises a fault-tolerant writing (FTW) protocol using the transaction records as specified by TianoCore.org.

5. The method of claim 1 further including, if a fault occurs during the erasing of content in the working store, then copying variable records from the spare region, writing the copied variable records from the spare region into the primary region, and restarting the firmware updating after a subsequent device boot.

6. The method of claim 5 further including, if a fault occurs during the erasing of the variable records in the primary region, then aborting the firmware updating, and restarting the firmware updating after a subsequent device boot.

7. The method of claim 6 further including, if a fault occurs during the copying of the variable records from the firmware update payload or during the writing of the copied variable records to the primary region, then aborting the firmware updating, and restarting the firmware updating after a subsequent device boot.

8. The method of claim 7 further including, if a fault occurs subsequent to the copying of the variable records from the firmware update payload or subsequent to the writing of the copied variable records to the primary region, then initializing the working store in the primary region and resuming normal device operations.

9. The method of claim 8 further including, if a fault occurs during the erasing of the variable records in the spare region, then initializing the working store in the primary region and resuming normal device operations.

10. The method of claim 9 in which the firmware updating is a last step performed in a firmware over the air update.

11. A device, comprising:

one or more processors;

a network interface; and

one or more hardware-based memory devices storing computer-readable instructions which, when executed by the one or more processors, cause the device to;

receive, over the network interface, a firmware update payload of firmware variables as part of a firmware over the air (FOTA) update process,

use a secure spare region of a non-volatile memory device to create a back-up of firmware variables contained in a secure primary region of the non-volatile memory device,

write the firmware variables from the payload into the primary region,

if a fault occurs in the FOTA update process, use the back-up of the firmware variables to set the device to a known good boot state, and

erase the back-up if the firmware variables from the payload are successfully written to the primary region.

12. The device of claim 11 further including, in the event of a fault, causing the device to restart the FOTA update process after a subsequent boot of the device.

13. The device of claim 11 in which the firmware variables are written using a fault-tolerant write (FTW) process using transaction records that are stored in a working store implemented in the non-volatile memory device.

14. The device of claim 11 in which the firmware variables describe one or more of configuration setup, vendor data, OEM (original equipment manufacturer) data, language information, input/output or error handling interfaces, or boot order.

15. The device of claim 11 in which the FOTA update process utilizes an update driver in a UEFI (Unified Extensible Firmware Interface) and the firmware variables are UEFI variables, wherein the update driver is implemented as a UEFI DXE (Driver Execution Environment) driver.

16. The device of claim 11 further including causing the device to expose one or more switches for selectively enabling or disabling the variable writing in the FOTA update process wherein a switch comprises a version of currently installed firmware on the device that is compared to a version of firmware in the update payload, and wherein the variable writing in the FOTA update process is enabled if the installed firmware version is older than the update firmware version.

17. The device of claim 11 further including causing the device to validate the firmware update payload prior to commencing the variable writing in an FOTA update process wherein the validating is performed using a cryptographic process.

18. The device of claim 17 in which the validating comprises matching a runtime-calculated hash of variable records with a hash of variable records contained in a firmware update payload received from a remote source, wherein the hash of variable records contained in the firmware update payload is stored in a secure boot manifest in the firmware update payload.

19. One or more hardware-based computer-readable memory devices storing computer-executable instructions which, when executed by one or more processors disposed in a computer server, cause the server to:

incorporate a whitelist of UEFI (Unified Extensible Firmware Interface) variables in a firmware update payload, the whitelist of UEFI variables specifying a device state that is persisted after a firmware over the air (FOTA) update of a remote device is completed; and

transmit the firmware update payload to the remote device over a network.

20. The one or more hardware-based computer-readable memory devices of claim 19 in which the remote device uses the firmware update payload to repave UEFI variables contained in a secure non-volatile store, wherein the UEFI variables are backed up to a spare region in the secure non-volatile store to enable the FOTA update to be fault-tolerant.