Microsoft has done a number of things to ensure a secure hypervisor: Security Development Lifecycle The Microsoft Security Development Lifecycle (SDL) is one of the main ways that Microsoft assures quality software. In place since 2004, the SDL has improved product quality by implementing strict quality gates, process improvements, and other guidance throughout the entire software-development process. By being put in place at the earliest possible time, before a line of code has been written, the SDL helps eliminate security issues before the product ships and can affect users.
For more information, you can read the following white paper, which provides guidance on how Microsoft implemented the SDL: http://www.microsoft.com/downloads/details.aspx?FamilyID=2412c443-27f6-4aac-9883-f55ba5b01814&displaylang=en. Keep in mind that this is only a guide and that not all the steps Microsoft followed are publically available.
Separate address spaces. Both the hypervisor and the host operating system maintain separate address spaces. An address space refers to a specific location in memory. By ensuring that there are separate address spaces for both components, the host operating system can’t read or access the hypervisor address space and vice versa.
No third-party code. The hypervisor included as part of Hyper-V doesn’t include any thirdparty code. Other hypervisors include device drivers or other drivers that were submitted by third parties. By having all code in the hypervisor go through the SDL, Microsoft can ensure the stability of the hypervisor as a whole.
Guest-to-guest communication. No communication that takes place between guests over synthetic devices goes through the hypervisor. This reduces the chance of a man-in-themiddle attack in the hypervisor, where someone injects a driver at the hypervisor level that sniffs data going between two VMs.
No shared memory between guests. Each guest has its own memory space. This means the memory allocated to those VMs is exclusive and can’t be accessed from other VMs.
Inability of guests to affect hardware I/O. All I/O for synthetic devices in VMs is handled in the Virtualization Service Provider / Virtualization Service Client (VSP/VSC) model, which sits above the hypervisor layer. Also, the I/O model of the VSP/VSC architecture sends out requests on behalf of the VM—the VM itself doesn’t send I/O requests.
Hypervisor access. The host and guests are unable to write to the hypervisor; rather, they communicate with the hypervisor via the well-defined Hypercall API. This ensures that the hypervisor can’t be modified.
Source of Information : Sybex Windows Server 2008 Hyper-V Insiders Guide to Microsofts Hypervisor
For more information, you can read the following white paper, which provides guidance on how Microsoft implemented the SDL: http://www.microsoft.com/downloads/details.aspx?FamilyID=2412c443-27f6-4aac-9883-f55ba5b01814&displaylang=en. Keep in mind that this is only a guide and that not all the steps Microsoft followed are publically available.
Separate address spaces. Both the hypervisor and the host operating system maintain separate address spaces. An address space refers to a specific location in memory. By ensuring that there are separate address spaces for both components, the host operating system can’t read or access the hypervisor address space and vice versa.
No third-party code. The hypervisor included as part of Hyper-V doesn’t include any thirdparty code. Other hypervisors include device drivers or other drivers that were submitted by third parties. By having all code in the hypervisor go through the SDL, Microsoft can ensure the stability of the hypervisor as a whole.
Guest-to-guest communication. No communication that takes place between guests over synthetic devices goes through the hypervisor. This reduces the chance of a man-in-themiddle attack in the hypervisor, where someone injects a driver at the hypervisor level that sniffs data going between two VMs.
No shared memory between guests. Each guest has its own memory space. This means the memory allocated to those VMs is exclusive and can’t be accessed from other VMs.
Inability of guests to affect hardware I/O. All I/O for synthetic devices in VMs is handled in the Virtualization Service Provider / Virtualization Service Client (VSP/VSC) model, which sits above the hypervisor layer. Also, the I/O model of the VSP/VSC architecture sends out requests on behalf of the VM—the VM itself doesn’t send I/O requests.
Hypervisor access. The host and guests are unable to write to the hypervisor; rather, they communicate with the hypervisor via the well-defined Hypercall API. This ensures that the hypervisor can’t be modified.
Source of Information : Sybex Windows Server 2008 Hyper-V Insiders Guide to Microsofts Hypervisor
|
|
0 comments
Post a Comment