Microsoft Technology Licensing, LLC

Gregory John Colombo

Jason Lin

Mehmet Iyigun

Hari R Pulapaka

Kenneth Dean Johnson

Arun Upadhyaya Kishan

Neill Michael Clift

Weidong Cui

Matthew Ryan Miller

Jin Lin

Ben Niu

Niraj Majmudar

Garrett Leischner

Evan Lincoln Tice

Shayne Daniel Hiet-Block

Stephen L Hufnagel

Yevgeniy Bak

Alain Franck Gefflaut

Kevin Michael Broas

Thomas Fahrig

Arsalan Ahmad

Michael Bishop Ebersol

James Andrew Goossen

Wen Jia Liu

Ahmed Saruhan Karademir

Logananth Seetharaman

Graham Wong

Christopher Peter Kleynhans

Stephen Louis-Essman Hufnagel

Shawn Michael Denbow

Mark Livschitz

Steven Michel Pronovost

Thobias Jones

Michael Charles Crandall

Steve Michel Pronovost

A program is executed using a call stack and shadow stack. The call stack includes frames having respective return addresses. The frames may also store variables and/or parameters. The shadow stack stores duplicates of the return addresses in the call stack. The call stack and the shadow stack are maintained by, (i) each time a function is called, adding a corresponding stack frame to the call stack and adding a corresponding return address to the shadow stack, and (ii) each time a function is exited, removing a corresponding frame from the call stack and removing a corresponding return address from the shadow stack. A backtrace of the program's current call chain is generated by accessing the return addresses in the shadow stack. The outputted backtrace includes the return addresses from the shadow stack and/or information about the traced functions that is derived from the shadow stack's return addresses.

Stack traces using shadow stack

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

Communicating a low-latency event across a virtual machine boundary. Based on an event signaling request by a first process running at a first virtual machine, the first virtual machine updates a shared register that is accessible by a second virtual machine. Updating the shared register includes updating a signal stored in the shared register. The first virtual machine sends an event signal message, which includes a register identifier, through a virtualization fabric to the second virtual machine. The second virtual machine receives the event signaling message and identifies the register identifier from the message. Based on the register identifier, the second virtual machine reads the shared register, identifying a value of the signal stored in the shared register. Based at least on the value of the signal comprising a first value, the second virtual machine signals a second process running at the second virtual machine.

Low-latency events across a virtual machine boundary

A service control manager manages one or more services on a computing device, such as creating processes that host the services, stopping the processes that host the services, and so forth. The service control manager also provides a request to a resource manager to reserve, monitor, and/or place limitations on resources for each of the one or more services. For example, the service control manager can request to be notified when resource usage by a service exceeds a resource usage threshold value. These resources are various resources of the computing device, such as a processor (CPU), memory, storage device input/output (I/O), network usage, and so forth. If the usage of a resource by a service satisfies the resource usage threshold value for that resource for that service, then the resource manager notifies the service control manager so the service control manager can take an appropriate remedial action.

Resource management for services

Embodiments disclosed herein are related to systems, methods, and computer readable medium for allocating one or more system resources for the exclusive use of an application. The embodiments include receiving a request for an exclusive allocation of one or more system resources for a first application, the one or more system resources being useable by the first application and one or more second applications; determining an appropriate amount of the one or more system resources that are to be allocated exclusively to the first application; and partitioning the one or more system resources into a first portion that is allocated for the exclusive use of the first application and a second portion that is not allocated for the exclusive use of the first application, the second portion being available for the use of the one or more second applications.

Operating system support for game mode

In response to a memory allocation request received from an application thread, a random number is obtained (e.g., from a random number list previously populated with multiple random numbers). A starting location in at least a portion of a bitmap associated with a region including multiple blocks of the memory is determined based on the random number. A portion of the bitmap is scanned, beginning at the starting location, to identify a location in the bitmap corresponding to an available block of the multiple blocks, and an indication of this available block is returned to the application thread.

Lightweight random memory allocation

In a first thread of a process a determination is made that a current value at a target address is not a desired value. In response to this determination, a first application programming interface (API) is invoked to indicate that the first thread is to sleep and be woken up when a second thread modifies the value at the target address. When a second thread modifies the value at the target address, the second thread invokes a second API to indicate that the value at the target address has been modified. In response to the second API being invoked, the first thread is woken up.

Wait on address synchronization interface

Growing community of inventors

Kirkland, WA, United States of America

Gregory John Colombo