DXE Driver Loading via Dummy Protocol for Dual Boot Initialization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Computing devices configured for dual initialization implementations, such as UEFI and LINUXBOOT®, face reduced security and increased initialization times due to the conventional loading of all DXE drivers required for UEFI, even when LINUXBOOT® only requires a subset.
Innovation Solution
A dual initialization implementation computing device uses a dummy protocol to determine which DXE drivers to load based on enabled initialization, providing a first subset required for UEFI but not LINUXBOOT®, and a second subset required for both, thereby optimizing driver loading and reducing unnecessary dependencies.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If all DXE drivers required for UEFI are loaded in dual initialization implementation devices, then UEFI functionality is supported, but security is reduced and initialization time increases
Solution Approach 1:
The patent segments the DXE driver set into two distinct subsets: a first subset containing drivers required exclusively for UEFI initialization, and a second subset containing drivers required for both UEFI and LINUXBOOT initialization. This segmentation enables selective loading based on the active initialization implementation, preventing unnecessary drivers from being loaded and thereby reducing initialization time while maintaining dual initialization support
Solution Approach 2:
The patent applies partial action by loading only the necessary subset of DXE drivers rather than the complete set required for UEFI. When LINUXBOOT initialization is active, only the second subset (drivers common to both implementations) is loaded, representing a partial loading strategy that optimizes performance by avoiding excessive driver loading
2Adaptability or versatility
If all DXE drivers required for UEFI are loaded in dual initialization implementation devices, then UEFI functionality is supported, but security is reduced
Solution Approach 1:
The patent segments the DXE driver set into two distinct subsets: a first subset containing drivers required exclusively for UEFI initialization, and a second subset containing drivers required for both UEFI and LINUXBOOT initialization. This segmentation enables selective loading based on the active initialization implementation, preventing unnecessary drivers from being loaded and thereby reducing initialization time while maintaining dual initialization support
Solution Approach 2:
The patent extracts and removes the first subset of DXE drivers (UEFI-specific drivers) from the loading process when LINUXBOOT initialization is active. This extraction principle directly addresses security concerns by ensuring that drivers not required for the active initialization implementation are not present in the system, thereby eliminating potential security vulnerabilities while preserving dual initialization capability
3Ease of manufacture
If a dummy protocol is provided in the memory system, then UEFI drivers can be loaded, but driver loading complexity increases
Solution Approach 1:
The patent introduces a dummy protocol as an intermediary mechanism that serves as a dependency marker for UEFI-specific DXE drivers. This dummy protocol acts as a mediator that simplifies the driver loading logic by providing a clear conditional check: if the dummy protocol is present, load UEFI drivers; if absent, load only common drivers. This intermediary approach reduces overall system complexity despite adding a protocol element
Data Source
AI summary
A multi-initialization implementation DXE driver loading system includes a chassis housing an initialization subsystem coupled to a memory system and a storage system. The storage system stores first DXE driver(s) required for a first initialization implementation but not a second initialization implementation and each including a dummy protocol identifier identifying a dummy protocol in its dependency section, and second DXE driver(s) required for both the first and second initialization implementations and each not including the dummy protocol identifier in its dependency section. If the second initialization implementation is enabled, the initialization subsystem does not provide the dummy protocol in the memory system, which prevents it from providing the first DXE driver(s) in the memory system due to a dependency requirement provided by the dummy protocol identifier in their dependency sections not being satisfied, while providing the second DXE driver(s) in the memory system for use in performing an initialization process.