Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Described herein is a system and method for latency-aware thread scheduled. For each processor core, an estimated cost to schedule a particular thread on the processor core is calculated. The estimated cost to schedule can be a period of time between the scheduling decision and the point in time where the scheduled thread begins to run. For each processor core, an estimated cost to execute the particular thread on the processor core is calculated. The estimated cost to execute can be a period of time spent actually running the particular thread on a particular processor core. A determination as to which processor core to utilize for execution of the particular thread based, at least in part, upon the calculated estimated costs to schedule the particular thread and/or the calculated estimated costs to execute the particular thread. The particular thread can be scheduled to execute on the determined processor core.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Configuring a node. A method includes at a first configuration layer, modifying configuration settings. The method further includes propagating the modified configuration settings to one or more other configuration layers implemented at the first configuration layer to configure a node.

Abstract: 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.