Secure VM Startup via Segmented IPL and Hypervisor Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud computing environments face challenges in ensuring the security of virtual machines (VMs) from hypervisors and other VMs, particularly in scenarios where multiple customers' data is stored on the same server.
Innovation Solution
The method involves using a hypervisor to dispatch a virtual machine (VM) on a host server, where the VM includes a reboot instruction. This reboot instruction is triggered by the hypervisor to restart the VM in a secure mode, utilizing an initial program load (IPL) mechanism and an encrypted image of the VM, along with an unencrypted bootstrap component.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the hypervisor loads and executes the VM image directly, then the VM can start quickly, but the hypervisor gains access to the VM data compromising security
Solution Approach 1:
The VM image is segmented into two distinct parts: an encrypted image portion and an unencrypted bootstrap component. The encrypted image is stored in a first memory location while the bootstrap component is stored in a second memory location. This segmentation allows the bootstrap to execute and initiate VM operation without requiring the hypervisor to decrypt or access the encrypted image data, thus maintaining security while enabling startup functionality.
Solution Approach 2:
The encrypted VM image is prepared and loaded into memory in advance, along with the unencrypted bootstrap component. The bootstrap component is specifically designed to be executable without decryption, performing preliminary initialization tasks and setting up the environment needed to eventually access and decrypt the main image if required. This preliminary setup enables the VM to start securely without requiring the hypervisor to have access to encrypted data.
2Reliability
If the VM image is encrypted to protect data, then security is improved, but the hypervisor cannot access the VM data even when needed
Solution Approach 1:
The patent introduces an intermediary mechanism in the form of a secure interface control and decryption module that acts as a mediator between the encrypted VM image and the hypervisor. When the hypervisor needs to access VM data, it does so through this intermediary which handles the decryption process securely. The secure interface control receives requests from the hypervisor, performs the necessary decryption operations using stored decryption information, and provides the data without exposing the encryption keys or compromising overall security. This intermediary approach maintains both data protection and controlled accessibility.
3Productivity
If the hypervisor decrypts the VM image before execution, then the VM can run efficiently, but the decryption process exposes security vulnerabilities
Solution Approach 1:
The patent applies local quality by making different portions of the VM image have different encryption states. Specifically, the bootstrap component is kept unencrypted and stored in a separate memory location to enable efficient execution, while the main VM image remains encrypted and stored in a different location. This localized differentiation allows the system to have both an executable unencrypted portion for efficiency and an encrypted portion for security, avoiding the need to decrypt the entire image and thereby reducing security exposure.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method for starting a secure guest includes receiving, by a hypervisor that is executing on a host server, a request to dispatch a virtual machine (VM) on the host server. The VM is dispatched on the host server by the hypervisor. The VM includes a reboot instruction. The reboot instruction is triggered by the hypervisor to restart the VM in a secure mode.