Abstract: Techniques of implementing software filtered non-volatile memory in a computing device are disclosed herein. In one embodiment, a method includes detecting an entry being written to a guest admin submission queue (gASQ) by a memory driver of a virtual machine hosted on the computing device. Upon detecting the entry written to the gASQ by the memory driver, the command in the entry is analyzed to determine whether the command is allowed based on a list of allowed or disallowed commands. In response to determining that the command in the entry is not allowed, without sending the command to the non-volatile memory, generating an execution result of the command in response to the entry being written to the gASQ by the memory driver. As such, potentially harmful commands from the memory driver are prevented from being executed by the non-volatile memory.

Abstract: Techniques of implementing software filtered non-volatile memory in a computing device are disclosed herein. In one embodiment, a method includes detecting an entry being written to a guest admin submission queue (gASQ) by a memory driver of a virtual machine hosted on the computing device. Upon detecting the entry written to the gASQ by the memory driver, the command in the entry is analyzed to determine whether the command is allowed based on a list of allowed or disallowed commands. In response to determining that the command in the entry is not allowed, without sending the command to the non-volatile memory, generating an execution result of the command in response to the entry being written to the gASQ by the memory driver. As such, potentially harmful commands from the memory driver are prevented from being executed by the non-volatile memory.

Abstract: Techniques of implementing software filtered non-volatile memory in a computing device are disclosed herein. In one embodiment, a method includes detecting an entry being written to a guest admin submission queue (gASQ) by a memory driver of a virtual machine hosted on the computing device. Upon detecting the entry written to the gASQ by the memory driver, the command in the entry is analyzed to determine whether the command is allowed based on a list of allowed or disallowed commands. In response to determining that the command in the entry is not allowed, without sending the command to the non-volatile memory, generating an execution result of the command in response to the entry being written to the gASQ by the memory driver. As such, potentially harmful commands from the memory driver are prevented from being executed by the non-volatile memory.

Abstract: Techniques of implementing software filtered non-volatile memory in a computing device are disclosed herein. In one embodiment, a method includes detecting an entry being written to a guest admin submission queue (gASQ) by a memory driver of a virtual machine hosted on the computing device. Upon detecting the entry written to the gASQ by the memory driver, the command in the entry is analyzed to determine whether the command is allowed based on a list of allowed or disallowed commands. In response to determining that the command in the entry is not allowed, without sending the command to the non-volatile memory, generating an execution result of the command in response to the entry being written to the gASQ by the memory driver. As such, potentially harmful commands from the memory driver are prevented from being executed by the non-volatile memory.

Abstract: Techniques of implementing software filtered non-volatile memory in a computing device are disclosed herein. In one embodiment, a method includes detecting an entry being written to a guest admin submission queue (gASQ) by a memory driver of a virtual machine hosted on the computing device. Upon detecting the entry written to the gASQ by the memory driver, the command in the entry is analyzed to determine whether the command is allowed based on a list of allowed or disallowed commands. In response to determining that the command in the entry is not allowed, without sending the command to the non-volatile memory, generating an execution result of the command in response to the entry being written to the gASQ by the memory driver. As such, potentially harmful commands from the memory driver are prevented from being executed by the non-volatile memory.

Abstract: Moving scheduling of processor time for virtual processors (VPs) out of a virtualization hypervisor. A host operating system schedules VP (virtual processor) processor time. The host operating system creates VP backing threads, one for each VP of each virtual machine. There is a one-to-one mapping between each VP thread in the host operating system and each VP in the hypervisor. When a VP thread is dispatched for a slice of processor time, the host operating system calls into the hypervisor to have the hypervisor start executing the VP, and the hypervisor may perform a processor context switch for the VP. Of note is the security separation between VP scheduling and VP context switching. The hypervisor manages VP context switching in kernel mode while VP scheduling is performed in user mode. There is a security/interface boundary between the unit that schedules VP processor time and the hypervisor.

Abstract: A virtual machine manager facilitates selective code integrity enforcement. A virtual machine manager (or other higher privileged entity) can verify the integrity of code in memory pages, and a virtual processor running in kernel mode executes the code on a memory page only if the virtual machine manager (or other higher privileged entity) has verified the code integrity of that code. However, the virtual machine manager need not verify the integrity of code in memory pages when the virtual processor is running in user mode. Rather, an operating system running on the virtual processor can apply any of a variety of policies (e.g., optionally perform any of a variety of different checks or verifications of the code) to determine whether the code can be executed in user mode.

Abstract: Techniques of implementing software filtered non-volatile memory in a computing device are disclosed herein. In one embodiment, a method includes detecting an entry being written to a guest admin submission queue (gASQ) by a memory driver of a virtual machine hosted on the computing device. Upon detecting the entry written to the gASQ by the memory driver, the command in the entry is analyzed to determine whether the command is allowed based on a list of allowed or disallowed commands. In response to determining that the command in the entry is not allowed, without sending the command to the non-volatile memory, generating an execution result of the command in response to the entry being written to the gASQ by the memory driver. As such, potentially harmful commands from the memory driver are prevented from being executed by the non-volatile memory.

Abstract: Techniques for a recovery environment for a virtual machine are described herein. Generally, a recovery environment provides a secure environment in which a damaged virtual machine can undergo repair procedures without compromising the security of the damaged virtual machine. In at least some implementations, a recovery environment represents an instance of a virtual machine that is executed to wrap a damaged virtual machine to enable the damaged virtual machine to be repaired.

Abstract: A virtual machine manager facilitates selective code integrity enforcement. A virtual machine manager (or other higher privileged entity) can verify the integrity of code in memory pages, and a virtual processor running in kernel mode executes the code on a memory page only if the virtual machine manager (or other higher privileged entity) has verified the code integrity of that code. However, the virtual machine manager need not verify the integrity of code in memory pages when the virtual processor is running in user mode. Rather, an operating system running on the virtual processor can apply any of a variety of policies (e.g., optionally perform any of a variety of different checks or verifications of the code) to determine whether the code can be executed in user mode.

Abstract: A virtual machine manager facilitates selective code integrity enforcement. A virtual machine manager (or other higher privileged entity) can verify the integrity of code in memory pages, and a virtual processor running in kernel mode executes the code on a memory page only if the virtual machine manager (or other higher privileged entity) has verified the code integrity of that code. However, the virtual machine manager need not verify the integrity of code in memory pages when the virtual processor is running in user mode. Rather, an operating system running on the virtual processor can apply any of a variety of policies (e.g., optionally perform any of a variety of different checks or verifications of the code) to determine whether the code can be executed in user mode.

Abstract: Embodiments relate to moving scheduling of processor time for virtual processors (VPs) out of a virtualization hypervisor. In one embodiment, a host operating system schedules VP processor time. The host operating system creates VP backing threads, one for each VP of each VM. There is a one-to-one mapping between each VP thread in the host operating system and each VP in the hypervisor. When a VP thread is dispatched for a slice of processor time, the host operating system calls into the hypervisor to have the hypervisor start executing the VP, and the hypervisor may perform a processor context switch for the VP. Of note is the security separation between VP scheduling and VP context switching. The hypervisor manages VP context switching in kernel mode while VP scheduling is performed in user mode. There is a security/interface boundary between the unit that schedules VP processor time and the hypervisor.

Abstract: An operating system running on a computing device, also referred to herein as a host device, uses containers for hardware resource partitioning. A container can include one or more of various different components, such as a base operating system, a user-mode environment, an application, virtual devices, combinations thereof, and so forth. One or more container templates are maintained for a computing device, and in response to a request to create a new container, a template container is copied into memory of the computing device to create the new container. The template container includes the various components of the container, and these components are copied into memory of the computing device rather than being launched or started one after the other. Thus, time need not be expended starting the various components included in the container—the components are just copied into memory as a new container.

Abstract: Techniques for a recovery environment for a virtual machine are described herein. Generally, a recovery environment provides a secure environment in which a damaged virtual machine can undergo repair procedures without compromising the security of the damaged virtual machine. In at least some implementations, a recovery environment represents an instance of a virtual machine that is executed to wrap a damaged virtual machine to enable the damaged virtual machine to be repaired.

Abstract: A virtual machine manager (e.g., hypervisor) implements a virtual secure mode that makes multiple different virtual trust levels available to virtual processors of a virtual machine. Different memory access protections (such as the ability to read, write, and/or execute memory) can be associated with different portions of memory (e.g., memory pages) for each virtual trust level. The virtual trust levels are organized as a hierarchy with a higher level virtual trust level being more privileged than a lower virtual trust level, and programs running in the higher virtual trust level being able to change memory access protections of a lower virtual trust level. The number of virtual trust levels can vary, and can vary for different virtual machines as well as for different virtual processors in the same virtual machine.

Abstract: Memory page de-duplication in a computer system that includes a plurality of virtual machine partitions managed by a hypervisor, where each virtual machine is assigned a different dedicated memory partition, may include: identifying, by the hypervisor, a plurality of identical memory pages in memory of one or more dedicated memory partitions; assigning, by the hypervisor, one of the identical memory pages as a master page; mapping, for each virtual machine having an identical memory page, each of the identical memory pages to the master page; and directing, by the hypervisor, reads of the memory page to the master page.

Abstract: Memory page de-duplication in a computer system that includes a plurality of virtual machine partitions managed by a hypervisor, where each virtual machine is assigned a different dedicated memory partition, may include: identifying, by the hypervisor, a plurality of identical memory pages in memory of one or more dedicated memory partitions; assigning, by the hypervisor, one of the identical memory pages as a master page; mapping, for each virtual machine having an identical memory page, each of the identical memory pages to the master page; and directing, by the hypervisor, reads of the memory page to the master page.

Abstract: A virtual machine manager (e.g., hypervisor) implements a virtual secure mode that makes multiple different virtual trust levels available to virtual processors of a virtual machine. Different memory access protections (such as the ability to read, write, and/or execute memory) can be associated with different portions of memory (e.g., memory pages) for each virtual trust level. The virtual trust levels are organized as a hierarchy with a higher level virtual trust level being more privileged than a lower virtual trust level, and programs running in the higher virtual trust level being able to change memory access protections of a lower virtual trust level. The number of virtual trust levels can vary, and can vary for different virtual machines as well as for different virtual processors in the same virtual machine.

Abstract: A virtual machine manager facilitates selective code integrity enforcement. A virtual machine manager (or other higher privileged entity) can verify the integrity of code in memory pages, and a virtual processor running in kernel mode executes the code on a memory page only if the virtual machine manager (or other higher privileged entity) has verified the code integrity of that code. However, the virtual machine manager need not verify the integrity of code in memory pages when the virtual processor is running in user mode. Rather, an operating system running on the virtual processor can apply any of a variety of policies (e.g., optionally perform any of a variety of different checks or verifications of the code) to determine whether the code can be executed in user mode.

Abstract: Memory page de-duplication in a computer system that includes a plurality of virtual machine partitions managed by a hypervisor, where each virtual machine is assigned a different dedicated memory partition, may include: identifying, by the hypervisor, a plurality of identical memory pages in memory of one or more dedicated memory partitions; assigning, by the hypervisor, one of the identical memory pages as a master page; mapping, for each virtual machine having an identical memory page, each of the identical memory pages to the master page; and directing, by the hypervisor, reads of the memory page to the master page.