Microsoft Technology Licensing, LLC

Other

Kenneth Dean Johnson

Matthew Ryan Miller

Mehmet Iyigun

Jason Lin

Gregory John Colombo

Yevgeniy Bak

Timothy William Burrell

Landy Wang

Richard John Black

Weidong Cui

Manuel Silverio Da Silva Costa

Miguel Oom Temudo De Castro

Jin Lin

Ben Niu

Niraj Majmudar

Shayne Daniel Hiet-Block

Arun Upadhyaya Kishan

Xin Zhang

Daniel A Tingley

Roy Williams

Jonathan E Lange

Pedro Miguel Sequeira De Justo Teixeira

Yimin Deng

Neeraj Kumar Singh

Nitin Kumar Goel

Pedro Miguel Teixeira

Sai Ganesh Ramachandran

Navin Narayan Pai

Chiuchin Chen

Russell Charles Hadley

YongKang Zhu

Jordan Thomas Rabet

Russell Bivens Keldorph

Joseph Norman Bialek

Adam M Zabrocki

Haim Cohen

Graham John Harper

Kenneth Johnson

Pranav Kant

Xiang Fan

Gabriel Thomas Kodjo Dos Reis

Gregory Justice Riggs

Grzegorz M Wroblewski

Tai Hing Tse

Shawn Daniel Hoffman

Yevgeniy M Bak

Various technologies described herein pertain to enforcing control flow integrity by adding instrumentation when source code is compiled or binary code is rewritten. An indirect call to a control transfer target (e.g., in the source code, in the binary code, etc.) can be identified. Moreover, the instrumentation can be inserted prior to the indirect call. The instrumentation can use a bit from a bitmap maintained by a runtime to verify whether the control transfer target is valid. When an executable image that includes the inserted instrumentation runs, execution can be terminated and/or other appropriate actions can be taken when the control transfer target is determined to be invalid; alternatively, execution can continue when the control transfer target is determined to be valid.

Control flow integrity enforcement at scale

Securely redirecting a system service routine via a provider service table. A service call provider is loaded within an operating system executing in a lower trust security zone. The service call provider comprises metadata indicating a system service routine to be redirected to the service call provider. Based on the metadata, a provider service table is built within a higher trust security zone. The service table redirects the system service routine to the service call provider. Memory page(s) associated with the provider service table are hardware protected, and a read-only view is exposed to the operating system. The provider service table is associated with a user-mode process. A service call for a particular system service routine is received by the operation system from the user-mode process and, based on the provider service table being associated with the user-mode process, the service call is directed to the service call provider.

Securely redirecting system service routines

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

Dynamically overriding a function based on a capability set. A computer system reads a portion of an executable image file. The portion includes a first memory address corresponding to a first callee function implementation. The first memory address was inserted into the portion by a compiler toolchain. Based on extensible metadata included in the executable image file, and based on a capability set that is specific to the computer system, the computer system determines a second memory address corresponding to a second callee function implementation. Before execution of the portion, the computer system modifies the portion to replace the first memory address with the second memory address.

Dynamically overriding a function based on a capability set

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

Preventing the observation of the side effects of mispredicted speculative execution flows using restricted speculation. In an embodiment a microprocessor comprises a register file including a plurality of entries, each entry comprising a value and a flag. The microprocessor (i) sets the flag corresponding to any entry whose value results from a memory load operation that has not yet been retired or cancelled, or results from a calculation that was derived from a register file entry whose corresponding flag was set, and (ii) clears the flag corresponding to any entry when the operation that generated the entry's value is retired. The microprocessor also comprises a memory unit that is configured to hold any memory load operation that uses an address whose value is calculated based on a register file entry whose flag is set, unless all previous instructions have been retired or cancelled.

Speculative side-channel attack mitigations

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.

Virtual machine manager facilitated selective code integrity enforcement

A system for exception handling is configured to, in response to detection of an exception during a function call, search for an exception handler to handle the detected exception by unwinding a stack across a plurality of frames. A binary includes functions associated with one of a first application binary interface (ABI) or a second ABI. The stack includes a transition frame created between frames of the first ABI and the second ABI during execution of the binaries. The system is configured to detect the transition frame in the stack when encountering a change from a frame of one ABI to a frame of another ABI, and translate an interface context therebetween to handle the exception.

Stack frame unwinding for exception handling

Speculative side channels exist when memory is accessed by speculatively-executed processor instructions. Embodiments use uncacheable memory mappings to close speculative side channels that could allow an unprivileged execution context to access a privileged execution context's memory. Based on allocation of memory location(s) to the unprivileged execution context, embodiments map these memory location(s) as uncacheable within first page table(s) corresponding to the privileged execution context, but map those same memory locations as cacheable within second page table(s) corresponding to the unprivileged execution context. This prevents a processor from carrying out speculative execution of instruction(s) from the privileged execution context that access any of this memory allocated to the unprivileged execution context, due to the unprivileged execution context's memory being mapped as uncacheable for the privileged execution context. Performance for the unprivileged execution context is substantially unaffected, however, since this memory is mapped as cacheable for the unprivileged execution context.

Speculative side channel attack mitigation using uncacheable memory

Each program thread running on a computing device has an associated data stack and control stack. A stack displacement value is generated, which is the difference between the memory address of the base of the data stack and the memory address of the base of the control stack, and is stored in a register of a processor of the computing device that is restricted to operating system kernel use. For each thread on which return flow guard is enabled, prologue and epilogue code is added to each function of the thread (e.g., by a memory manager of the computing device). The data stack and the control stack each store a return address for the function, and when the function completes the epilogue code allows the function to return only if the return addresses on the data stack and the control stack match.

Return flow guard using control stack identified by processor register

Techniques for memory image capture via memory write from a running system are described. In at least some embodiments, a request is received for an image of a portion of memory. Images of memory can be used for a variety of purposes, such as diagnosing and repairing error conditions for hardware and/or software, detecting unwanted and/or malicious processes (e.g., malware), general systems maintenance, and so forth. According to one or more embodiments, various techniques can be implemented to capture an image of a portion of memory. For example, an intermediate write to memory can be employed to write the image of the portion of memory to a memory buffer. Alternatively or additionally, an image of a portion of memory can be captured directly to storage.

Memory image capture via memory write from a running system

Growing community of inventors

Bellevue, WA, United States of America

Kenneth Dean Johnson