Volatile Memory Firmware Runtime Update Without Reboot
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Firmware runtime components, such as SMI handlers, can introduce security vulnerabilities in computing devices, requiring updates and reboots that are not feasible in environments demanding maximum uptime, like large-scale data centers.
Innovation Solution
Implementing a method to store and execute updated firmware runtime components in volatile memory without rebooting the device, allowing immediate security improvements with the option to permanently apply updates during a future reboot.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If firmware updates are applied to address security vulnerabilities, then security is improved, but device reboot is required which causes operational disruption
Solution Approach 1:
The patent segments the firmware update process into two distinct phases: (1) loading updated runtime components into volatile memory during runtime without reboot, and (2) permanently writing to non-volatile memory during a subsequent reboot. This segmentation allows security updates to be applied immediately in volatile memory while preserving operational continuity, and only requires reboot for permanent persistence, not for the update to take effect.
Solution Approach 2:
The patent performs preliminary action by loading updated firmware runtime components into volatile memory before a reboot occurs. This preliminary loading enables the security updates to be active and functional during runtime, while the actual permanent installation in non-volatile memory is deferred to a later reboot event. The update mechanism is prepared in advance but does not immediately require system restart.
2Stability of the object's composition
If firmware runtime components are updated in non-volatile memory, then updates are permanent, but device reboot is required to apply the updates
Solution Approach 1:
The patent divides the update application process into two stages: immediate application in volatile memory (no reboot needed) and permanent persistence in non-volatile memory (reboot needed). This segmentation decouples the timing of security effectiveness from the timing of permanent storage, allowing the system to choose when to reboot based on operational requirements rather than security requirements.
Solution Approach 2:
The patent introduces volatile memory as an intermediary between the update source and non-volatile memory. Updated runtime components are first loaded into volatile memory where they can be immediately executed, serving as a temporary staging area. This intermediary allows the system to apply updates without immediate reboot, while still enabling permanent installation later when a reboot does occur.
3Productivity
If firmware updates are delayed to avoid reboot, then operational continuity is maintained, but security vulnerabilities persist
Solution Approach 1:
The patent enables preliminary application of security updates in volatile memory during runtime, so that security patches are active and functional before any reboot occurs. This preliminary action in volatile memory ensures that security vulnerabilities are addressed immediately without waiting for a reboot cycle, while the permanent installation is deferred to a later appropriate time.
Solution Approach 2:
The patent creates a dynamic update mechanism where firmware runtime components can be updated in volatile memory during runtime operations. This dynamic approach allows the system to adapt security posture in real-time based on vulnerability severity and operational requirements, rather than being constrained by static reboot-based update cycles. The system can operate with updated security measures immediately while planning permanent installation later.
Data Source
AI summary
A computing device includes a processor, a volatile memory, and a non-volatile memory. The computing device receives a firmware update that includes updated firmware runtime components, such as updated runtime interrupt handlers (e.g. SMI handlers). The computing device stores the updated firmware runtime components in the volatile memory (e.g. RAM) of the device. The computing device also causes the updated firmware runtime components stored in the volatile memory to be used during the runtime of the computing device instead of one or more other firmware runtime components previously stored in the volatile memory. For example, the contents of one or more interrupt routing tables can be adjusted such that updated runtime interrupt handlers stored in volatile memory are used instead of previously installed and potentially insecure runtime interrupt handlers. On a subsequent reboot of the computing device, updated firmware runtime components stored in the non-volatile memory will be utilized.