EFI Embedded Hypervisor Root Mode Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current virtualization systems are vulnerable to viruses like the 'Blue pill' that can embed themselves on the root level, compromising the operating system's security, and existing hypervisor-based systems have security flaws due to kernel extensions, necessitating a more secure approach to virtualization.
Innovation Solution
Embedding a Hypervisor in the Extensible Firmware Architecture (EFI) with two components: one running on the root level for context switching and interrupt handling, and another on the non-root level for servicing the Virtual Machine Monitor (VMM) and enabling communication, using Trusted Execution Technology (TXT) for protection and verification of trusted code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a hypervisor is embedded in the operating system kernel, then virtualization functionality is integrated and easier to manage, but security is compromised due to kernel extensions being vulnerable to viruses like 'Blue pill'
Solution Approach 1:
The system divides the virtualization functionality into separate components: a hypervisor component embedded in EFI and a VMM component in the operating system. This segmentation isolates the critical virtualization code from the OS kernel, preventing viruses from compromising the entire system through kernel extensions while maintaining virtualization functionality.
Solution Approach 2:
The patent introduces EFI (Extensible Firmware Interface) as an intermediary layer between the hardware and the operating system. The hypervisor embedded in EFI acts as a mediator that handles context switching and interrupt handling, while the VMM in the OS handles VMM servicing. This intermediary structure prevents direct virus injection into the kernel while maintaining system functionality.
2Productivity
If the VMM runs on the root level with full privileges, then it can execute privileged instructions directly, but viruses can embed themselves on the root level and compromise the operating system
Solution Approach 1:
Instead of running the VMM on the root level with full privileges (traditional approach), the patent inverts the architecture by embedding the hypervisor in EFI and running the VMM on the non-root level within the operating system. This inversion maintains execution efficiency through direct hardware access while eliminating the security vulnerability of root-level virus embedding.
Solution Approach 2:
The hypervisor is embedded in the EFI layer before the operating system loads, performing preliminary setup of virtualization functionality. This preliminary action establishes a secure foundation that prevents viruses from gaining root-level privileges later, while still enabling efficient privileged instruction execution through the pre-configured hypervisor-VMM interface.
3Adaptability or versatility
If kernel extensions are used to provide virtualization functionality, then the OS can manage virtual machines, but the kernel extensions create security flaws that viruses can exploit
Solution Approach 1:
The patent extracts the critical virtualization code (hypervisor) from the operating system kernel and places it in the EFI layer. This extraction removes the security vulnerability of kernel extensions while preserving virtualization capability. The VMM remains in the OS but serves the extracted hypervisor, maintaining adaptability without compromising security integrity.
Data Source
AI summary
A first component of a Hypervisor is loaded into the memory upon start up. The first component is responsible for context switching and some interrupt handling. The first component of the Hypervisor runs on a root level. An OS is loaded into a highest non-root privilege level. A second component of the Hypervisor is loaded into OS space together with the OS, and running on the highest non-root privilege level. A Virtual Machine Monitor is running on the root level. The second component of the Hypervisor is responsible for (a) servicing the VMM, and (b) enabling communication between VMM code launched on non-root level with the first component of the Hypervisor to enable root mode for the VMM. A Virtual Machine is running on a user level under control of the VMM.