Firmware Update Staging for Secure Low-Stall Activation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing firmware update methods cause significant stall times in computing systems, leading to operational disruptions and security risks due to untrusted operating systems deploying unverified firmware images.
Innovation Solution
Implementing a platform root of trust (PRoT) to authenticate and manage firmware updates, allowing secure, vendor-verified patches to be applied during runtime or reboot without stalling the operating system by using a staging buffer and secure enclaves.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If firmware patches are delivered via WRMSR instruction to MSR 0xc0010020, then firmware updates can be applied at runtime, but system stall time increases significantly
Solution Approach 1:
The firmware update process is segmented into two independent phases: (1) firmware image delivery to a staging buffer, and (2) firmware activation by switching to the staged image. This segmentation allows delivery to occur without stalling the OS, while activation happens in a controlled manner that minimizes disruption.
Solution Approach 2:
The firmware image is delivered and staged in advance before activation is required. The OS can prepare the firmware image in a staging buffer during normal operation, so that when activation is needed, the switch can occur quickly without prolonged stalling.
2Adaptability or versatility
If the operating system controls firmware image deployment, then firmware can be updated dynamically, but security risks increase from untrusted OS deploying unverified firmware
Solution Approach 1:
A firmware authentication mechanism acts as an intermediary between the OS and the firmware update process. The OS can request firmware updates, but the actual deployment is controlled by authentication logic that verifies firmware images against cryptographic signatures and policies, preventing untrusted firmware from being installed.
Solution Approach 2:
The system implements feedback through authentication verification before firmware deployment. The firmware image is verified against cryptographic signatures and policy rules, and only authenticated images are deployed. This feedback loop ensures that even if the OS requests untrusted firmware, it will be rejected.
3Adaptability or versatility
If multiple dielets or chiplets are updated using traditional firmware patching, then comprehensive firmware updates are achieved, but total system stall time becomes unacceptably long
Solution Approach 1:
The firmware update process for multiple dielets is segmented so that firmware images can be delivered to staging buffers on all dielets in parallel without stalling the OS. The actual activation can then occur in a coordinated manner, reducing the cumulative stall time compared to sequential updates.
Solution Approach 2:
The system uses periodic or batched activation of staged firmware images across multiple dielets. Instead of activating all firmware updates simultaneously (which would cause prolonged stalling), the activation occurs in controlled batches or periodically, allowing the system to maintain operation while completing firmware updates across all dielets.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
Examples described herein a firmware update device to execute a second firmware, in place of execution of a first firmware, in response to an instruction that causes the firmware update device to execute the second firmware, wherein the second firmware is copied to a buffer prior to execution of the instruction. In some examples, one or more processors are to execute the instruction that causes the firmware update device to execute the second firmware. In some examples, prior to execution of the instruction, a device root of trust is also to validate the second firmware.