Microsoft Technology Licensing, LLC

Jin Lin

Mehmet Iyigun

Jason Lin

Niraj Majmudar

Michael Bishop Ebersol

Kenneth Dean Johnson

David Hepkin

Gregory John Colombo

Matthew John Woolman

Alexander Daniel Grest

Shayne Daniel Hiet-Block

Xin Zhang

Steve Pronovost

Bruce John Sherwin, Jr

Jonathan E Lange

Kevin Michael Broas

Jason Stewart Wohlgemuth

Qiang Wang

Aditya Bhandari

Wen Jia Liu

Kapil Vaswani

Jingbo Wu

Attilio Mainetti

Antoine Jean Denis Delignat-lavaud

Steven Adrian West

David Kimler Altobelli

Emily Cara Clemens

Stephanie Sumyi Luck

Dexuan Cui

Michael Halstead Kelley

Sarah Elizabeth Stephenson

Carolina Cecilia Perez-vargas

The techniques disclosed herein enable a system to configure a confidential virtual resource unit by provisioning a security component to a tenant's virtual resource unit. The system creates multiple different virtual trust layers within the confidential virtual resource unit. This creation effectively defines security boundaries between the virtual trust layers. The virtual trust layers are associated with different privileges, such that a higher privileged virtual trust layer is provided with more privileges compared to a lower privileged virtual trust layer. In one example, a lower privileged virtual trust layer may include basic virtual resource components (e.g., drivers, applications, processes, functions, workloads executing within a guest operating system) and a higher privileged virtual trust layer is the location to which a virtual security component is provisioned by the system.

Provisioning a security component from a cloud host to a guest virtual resource unit

Isolating resources of a virtual machine (VM) guest from a host operating system. A computer system receives an acceptance request from a guest partition corresponding to an isolated VM. The acceptance request identifies a guest memory page that is mapped into a guest physical address space of the guest partition, and a memory page visibility class. The computer system determines whether a physical memory page that is mapped to the guest memory page meets the memory page visibility class. The computer system sets a page acceptance indication for the guest memory page from an unaccepted state to an accepted state based on the physical memory page meeting the memory page visibility class.

Software isolation of virtual machine resources

A verified stack trace can be generated by utilizing information contained in a shadow stack, such as a hardware protected duplicate stack implemented for malware prevention and computer security. The shadow stack contains return addresses which are obtainable without requiring an unwinding of the traditional call stack. As such, triaging based on return address information can be performed more quickly and more efficiently, and with a reduced utilization of processing resources. Additionally, the generation of a verified stack trace can be performed, with such a verified stack trace containing return addresses that are known to be correct and not corrupted. The return addresses can either be read from the traditional call stack, or derived therefrom, and then verified by comparison to corresponding return addresses from the shadow stack, or they can be read directly from the shadow stack.

Verified stack trace generation and accelerated stack-based analysis with shadow stacks

Methods, systems, and computer program products for direct assignment of physical devices to confidential virtual machines (VMs). At a first guest privilege context of a guest partition, a direct assignment of a physical device associated with a host computer system to the guest partition is identified. The guest partition includes the first guest privilege context and a second guest privilege context, which is restricted from accessing memory associated with the first guest privilege context. The guest partition corresponds to a confidential VM, such that a memory region associated with the guest partition is inaccessible to a host operating system. It is determined, based on a policy, that the physical device is allowed to be directly assigned to the guest partition. Communication between the physical device and the second guest privilege context is permitted, such as by exposing the physical device on a virtual bus and/or forwarding an interrupt.

Direct assignment of physical devices to confidential virtual machines

Handling a memory fault based on detecting whether a memory pointer was invalidated by a pointer authentication (PA) failure. After an access to a memory pointer causes a memory fault, detecting that the memory pointer was invalidated by a PA failure includes creating a new memory pointer by replacing reserved bits of the memory pointer with a default value, and determining that the new memory pointer corresponds to a memory address that falls within executable memory. This determination includes determining that the memory address is within an executable memory page, determining that a call instruction is stored at a prior memory address that immediately precedes the memory address, and/or determining that the memory address corresponds to a code section of an executable file. The PA failure is handled based on logging the PA failure, terminating the application program, and/or resuming execution at an instruction stored at the memory address.

Pointer authentication failure detection

Performing shadow stack functionality for a thread in an audit mode includes initiating execution of a thread at the processor. Execution of the thread includes initiating execution of executable code of an application binary as part of the thread and enabling shadow stack functionality for the thread in an audit mode. Based at least on the execution of the thread in the audit mode, at least a portion of the shadow stack is enabled to be a circular stack. In response to determining that usage of the shadow stack has reached the defined threshold, one or more currently used entries of the shadow stack are overwritten, preventing the shadow stack from overflowing.

Circular shadow stack in audit mode

Enforcing shadow stack violations at module granularity, rather than at thread or process granularity. An exception is processed during execution of a thread based on code of an application binary, which is enabled for shadow stack enforcement, that calls an external module. The exception results from a mismatch between a return address popped from the thread's call stack and a return address popped from the thread's shadow stack. Processing the exception includes determining that the exception resulted from execution of an instruction in the external module, and determining whether or not the external module is enabled for shadow stack enforcement. Based at least on these determinations, execution of the thread is terminated when the external module is enabled for shadow stack enforcement, or the thread is permitted to continue executing when the external module is not enabled for shadow stack enforcement.

Shadow stack violation enforcement at module granularity

Enforcing shadow stack violations for dynamic code. A thread is executed at a processor, which includes generating a portion of dynamic code for execution by the thread, identifying a range of memory addresses where the portion of dynamic code is loaded in memory, and initiating execution of the portion of dynamic code. Based at least on execution of the thread, an exception triggered by a mismatch between a first return address popped from a call stack corresponding to the thread and a second return address popped from a shadow stack corresponding to the thread is processed. Processing the exception includes (i) determining whether the second return address popped from the shadow stack is within the identified range of addresses, and (ii) based on having determined that the second return address is within the range of addresses, initiating a shadow stack enforcement action.

Shadow stack enforcement range for dynamic code

Growing community of inventors

Seattle, WA, United States of America

Jin Lin