Abstract: Embodiments are directed to a distributed computing system comprising a plurality of compute nodes for providing resources to users and a hierarchy of two or more layers of controllers coupling the compute nodes to a user interface via a control plane, wherein at least one compute node receives a local application program interface (API) call from an application running on the at least one compute node, the local API call causing the at least one compute node to configure a local resource without requiring commands from the control plane.

Abstract: Embodiments are directed to a distributed computing system comprising a plurality of compute nodes for providing resources to users and a hierarchy of two or more layers of controllers coupling the compute nodes to a user interface via a control plane, wherein at least one compute node receives a local application program interface (API) call from an application running on the at least one compute node, the local API call causing the at least one compute node to configure a local resource without requiring commands from the control plane.

Abstract: Embodiments are directed to a distributed computing system comprising a plurality of compute nodes for providing resources to users and a hierarchy of two or more layers of controllers coupling the compute nodes to a user interface via a control plane, wherein at least one compute node receives a local application program interface (API) call from an application running on the at least compute node, the local API call causing the at least one compute node to configure a local resource without requiring commands from the control plane.

Abstract: Tenant and server platform coordination of the performance of atomic tasks that are to be performed by the platform, but which have at least a potential impact on the tenant. The server platform allows a particular tenant a timeframe within which the tenant itself may approve of initiation of each of one or more tasks. The server platform may protect itself from delayed action by imposing time constraints on the timeframe such that after the timeframe is elapsed, the tenant no longer has control over triggering the initiation of the particular task. Accordingly, the tenant is provided with flexibility on controlling initiation of a task performed by the server platform, while the server platform maintains a level of control to protect its resources and balances the needs of the various tenants.

Abstract: Embodiments are directed to a distributed computing system comprising a plurality of compute nodes for providing resources to users and a hierarchy of two or more layers of controllers coupling the compute nodes to a user interface via a control plane, wherein at least one compute node receives a local application program interface (API) call from an application running on the at least compute node, the local API call causing the at least one compute node to configure a local resource without requiring commands from the control plane.

Abstract: A distributed application may be updated by using information provided by the application to determine grouping, sequencing, and whether or not to advance an update sequence. The application may provide input to an update sequence, and may cause the update sequence to repair one or more replicas prior to updating. The update mechanism may be used to change the distributed application topology as well as make changes to the application executable code, application configuration, quest operating system, virtual machine, and host systems, among others. In some cases, the distributed application may use a quorum to determine which version is current, and the quorum may change during the update process.

Abstract: Methods, systems, and computer storage media for updating instances of a service application within nodes of a data center are provided. The system includes a state machine equipped for designating an earlier version of software running on some instances as a basement version and a newer version of software running on other instances as a latest version. The system also includes a compatibility mechanism responsible for allowing the basement version, the latest version, and other versions of the service application therebetween to interact using a data structure associated within the earlier version, or lowest common version of the service application. The compatibility mechanism is located apart from core logic of the service application. The activities of the state machine and the compatibility mechanism allow the instances to communicate with each other (using the lowest common version) while exposing just the validated version(s) of the service application to the client.

Abstract: Tenant and server platform coordination of the performance of atomic tasks that are to be performed by the platform, but which have at least a potential impact on the tenant. The server platform allows a particular tenant a timeframe within which the tenant itself may approve of initiation of each of one or more tasks. The server platform may protect itself from delayed action by imposing time constraints on the timeframe such that after the timeframe is elapsed, the tenant no longer has control over triggering the initiation of the particular task. Accordingly, the tenant is provided with flexibility on controlling initiation of a task performed by the server platform, while the server platform maintains a level of control to protect its resources and balances the needs of the various tenants.

Abstract: Systems and methods for automatically reverse engineering an input data format using dynamic data flow analysis. Combining input data with a simulated execution of the binary program using the input data and analyzing the use of the data by the program to generate a BNL-like grammar representing the input data format. The input data can be application level protocols, network protocols or formatted files.

Abstract: Methods, systems, and computer-readable media for facilitating coordination between a fabric controller of a cloud-computing network and a service application running in the cloud-computing network are provided. Initially, an update domain (UD) that includes role instance(s) of the service application is selected, where the service application represents a stateful application is targeted for receiving a tenant job executed thereon. The process of coordination involves preparing the UD for execution of the tenant job, disabling the role instance(s) of the UD to an offline condition, allowing the tenant job to execute, and restoring the role instance(s) to an online condition upon completing execution of the tenant job.

Abstract: Methods, systems, and computer storage media for updating instances of a service application within nodes of a data center are provided. The system includes a state machine equipped for designating an earlier version of software running on some instances as a basement version and a newer version of software running on other instances as a latest version. The system also includes a compatibility mechanism responsible for allowing the basement version, the latest version, and other versions of the service application therebetween to interact using a data structure associated within the earlier version, or lowest common version of the service application. The compatibility mechanism is located apart from core logic of the service application. The activities of the state machine and the compatibility mechanism allow the instances to communicate with each other (using the lowest common version) while exposing just the validated version(s) of the service application to the client.

Abstract: A single application can be executed across multiple execution environments in an efficient manner if at least a relevant portion of the virtual memory assigned to the application was equally accessible by each of the multiple execution environments. A request by a process in one execution environment can, thereby, be directed to an operating system, or other core software, in another execution environment and can be made by a shadow of the requesting process in the same manner as the original request was made by the requesting process itself. Because of the memory invariance between the execution environments, the results of the request will be equally accessible to the original requesting process even though the underlying software that responded to the request may be executing in a different execution environment. A similar thread invariance can be maintained to provide for accurate translation of requests between execution environments.

Abstract: Methods, systems, and computer-readable media for facilitating coordination between a fabric controller of a cloud-computing network and a service application running in the cloud-computing network are provided. Initially, an update domain (UD) that includes role instance(s) of the service application is selected, where the service application represents a stateful application is targeted for receiving a tenant job executed thereon. The process of coordination involves preparing the UD for execution of the tenant job, disabling the role instance(s) of the UD to an offline condition, allowing the tenant job to execute, and restoring the role instance(s) to an online condition upon completing execution of the tenant job.

Abstract: The database (namespace) for storing component metadata for an application that is to be run in an isolated environment is isolated by an operating system by storing the component metadata in a local set of information associated with the isolated application instead of in a global namespace. The operating system utilizes this local metadata instead of the global database when components are employed. Registration data for components is placed within a manifest, enabling the operating system to determine the relationship between an application and a component or set of components used by the application.

Abstract: A distributed application may be updated by using information provided by the application to determine grouping, sequencing, and whether or not to advance an update sequence. The application may provide input to an update sequence, and may cause the update sequence to repair one or more replicas prior to updating. The update mechanism may be used to change the distributed application topology as well as make changes to the application executable code, application configuration, quest operating system, virtual machine, and host systems, among others. In some cases, the distributed application may use a quorum to determine which version is current, and the quorum may change during the update process.

Abstract: Malware may be identified based on attempts to use tainted data in certain ways, such as by attempting to execute the tainted data, by attempting to modify execution control based on tainted data, or by attempting to apply an existing function to the tainted data. A data's taint is determined based on the location from which the data originates. When data from a tainted source is moved to an otherwise non-tainted destination, the taint may be propagated from the source to the destination, to indicate that the destination is now of unknown safety. A component may be used to observe the operation of a process, in order to determine what data is being moved with respect to the process, and how that data is being used.

Abstract: Software typically changes over its useful lifetime. New versions of software are created to change or improve functionality, to add functionality, to correct coding errors, improve performance, to adapt to new hardware and for many other well-known reasons. The process of delivering new versions of software to users is called servicing the software. The operating system decides which version(s) of a piece of software satisfy dependencies of other software by creation of a context. The context may be used to organize and manage versions of software, to declare activation policies concerning the use of different versions of software and to service the versioned software. The context may include an activation service that maintains and manages resolution polices, resolves dependencies, constructs the environment in which an application runs and initiates the running of the software.

Abstract: A single application can be executed across multiple execution environments in an efficient manner if at least a relevant portion of the virtual memory assigned to the application was equally accessible by each of the multiple execution environments. A request by a process in one execution environment can, thereby, be directed to an operating system, or other core software, in another execution environment and can be made by a shadow of the requesting process in the same manner as the original request was made by the requesting process itself. Because of the memory invariance between the execution environments, the results of the request will be equally accessible to the original requesting process even though the underlying software that responded to the request may be executing in a different execution environment. A similar thread invariance can be maintained to provide for accurate translation of requests between execution environments.

Abstract: A single application can be executed across multiple execution environments in an efficient manner if at least a relevant portion of the virtual memory assigned to the application was equally accessible by each of the multiple execution environments. A request by a process in one execution environment can, thereby, be directed to an operating system, or other core software, in another execution environment and can be made by a shadow of the requesting process in the same manner as the original request was made by the requesting process itself. Because of the memory invariance between the execution environments, the results of the request will be equally accessible to the original requesting process even though the underlying software that responded to the request may be executing in a different execution environment. A similar thread invariance can be maintained to provide for accurate translation of requests between execution environments.

Abstract: The behavior of a system call may be modified. A modification component may pre-processes and/or post-process a system call to change the behavior of the system call. Pre-processing may involve modifying arguments to the system call, replacing one system call with another, intercepting the system call, etc. Post-processing may involve modifying results and/or side effects of a system call. The modification component may pre-process and/or post-process the system call without changes to the underlying kernel service routine that is normally invoked in response to the system call. Modifying the system call's behavior may be used to implement quality of service (QoS) constraints, to allow one operating system to emulate another, to provide information about memory layout to an application, or to serve other goals.