Abstract: Techniques for employing a decentralized sleep management service are described herein. In some instances, each computing device of a group of computing devices periodically shares information about itself with each other computing device of the group. With this information, each computing device within the group that is awake and capable of managing other devices selects a subset of devices to probe. The devices then probe this subset to determine whether the probed devices are asleep. In response to identifying a sleeping device, the probing device takes over management of the sleeping device. Managing the sleeping device involves informing other devices of the group that the sleeping device is being managed, in addition to monitoring requests for services on the sleeping device. In response to receiving a valid request for a service hosted by the sleeping device, the managing device awakens the sleeping device and ceases managing the now-woken device.

Abstract: A computing device requests access to an application object from a remote storage system in order to locally execute application functionality without hosting application resources. An accessed object is associated with an intent in the storage system and locked. Locking an object in combination with an intent prevents computing devices that are not performing the intent from accessing the object. An intent defines one or more operations to be performed with the requested object, which are serialized as intent steps and stored in the storage system. Upon executing an intent step, the computing device stores a log entry at the storage system signifying the step's completion. A locked object remains locked until the log entries indicate every intent step as complete. Different computing devices can unlock a locked object by executing any incomplete steps of an intent associated with the locked object.

Abstract: Storing an incoming data stream using successive files that are consecutively populated. The appropriate file to populate a given data stream portion into is determined by mapping the data stream offset to a file, and potentially also an address within that file. The successive files may be the same size, so that the file can be identified based on the data stream address (or offset) without the use of an index. Furthermore, the files may be easily named by having that size be some multiple of a binary power of bytes. That way, the files themselves can be automatically and named and identified by using the more significant bit or bits of the data stream offset to uniquely identify the file and establish ordering of the files. Replication may occur from a primary to a secondary store by transmitting the offset, and the actual data to be stored.

Abstract: Techniques for leveraging legacy code to deploy native-code desktop applications over a network (e.g., the Web) are described herein. These techniques include executing an application written in native code within a memory region that hardware of a computing device enforces. For instance, page-protection hardware (e.g., a memory management unit) or segmentation hardware may protect this region of memory in which the application executes. The techniques may also provide a narrow system call interface out of this memory region by dynamically enforcing system calls made by the application. Furthermore, these techniques may enable a browser of the computing device to function as an operating system for the native-code application. These techniques thus allow for execution of native-code applications on a browser of a computing device and, hence, over the Web in a resource-efficient manner and without sacrificing security of the computing device.

Abstract: A computing device requests access to an application object from a remote storage system in order to locally execute application functionality without hosting application resources. An accessed object is associated with an intent in the storage system and locked. Locking an object in combination with an intent prevents computing devices that are not performing the intent from accessing the object. An intent defines one or more operations to be performed with the requested object, which are serialized as intent steps and stored in the storage system. Upon executing an intent step, the computing device stores a log entry at the storage system signifying the step's completion. A locked object remains locked until the log entries indicate every intent step as complete. Different computing devices can unlock a locked object by executing any incomplete steps of an intent associated with the locked object.

Abstract: A computing device requests access to an application object from a remote storage system in order to locally execute application functionality without hosting application resources. An accessed object is associated with an intent in the storage system and locked. Locking an object in combination with an intent prevents computing devices that are not performing the intent from accessing the object. An intent defines one or more operations to be performed with the requested object, which are serialized as intent steps and stored in the storage system. Upon executing an intent step, the computing device stores a log entry at the storage system signifying the step's completion. A locked object remains locked until the log entries indicate every intent step as complete. Different computing devices can unlock a locked object by executing any incomplete steps of an intent associated with the locked object.

Abstract: A first set of replicated state machines includes a first state machine that compares a clock value included in a state update message incremented by a first amount, a clock value for the first state machine incremented by a second amount, and a current local wall clock value for the first state machine to determine a maximum value and assigns the maximum value as the clock value for the first state machine. Additionally, in response to a passage of an amount of time, the first state machine advances the clock value for the first state machine to its current local wall clock value and propagates this clock value to the other state machines in the first set of replicated state machines. The advancement of the clock value for all state machines even in the absence of state updates improves their ability to respond to distributed read requests.

Abstract: A first set of replicated state machines includes a first state machine that compares a clock value included in a state update message incremented by a first amount, a clock value for the first state machine incremented by a second amount, and a current local wall clock value for the first state machine to determine a maximum value and assigns the maximum value as the clock value for the first state machine. Additionally, in response to a passage of an amount of time, the first state machine advances the clock value for the first state machine to its current local wall clock value and propagates this clock value to the other state machines in the first set of replicated state machines. The advancement of the clock value for all state machines even in the absence of state updates improves their ability to respond to distributed read requests.

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: Storing an incoming data stream using successive files that are consecutively populated. The appropriate file to populate a given data stream portion into is determined by mapping the data stream offset to a file, and potentially also an address within that file. The successive files may be the same size, so that the file can be identified based on the data stream address (or offset) without the use of an index. Furthermore, the files may be easily named by having that size be some multiple of a binary power of bytes. That way, the files themselves can be automatically and named and identified by using the more significant bit or bits of the data stream offset to uniquely identify the file and establish ordering of the files. Replication may occur from a primary to a secondary store by transmitting the offset, and the actual data to be stored.

Abstract: A computing device requests access to an application object from a remote storage system in order to locally execute application functionality without hosting application resources. An accessed object is associated with an intent in the storage system and locked. Locking an object in combination with an intent prevents computing devices that are not performing the intent from accessing the object. An intent defines one or more operations to be performed with the requested object, which are serialized as intent steps and stored in the storage system. Upon executing an intent step, the computing device stores a log entry at the storage system signifying the step's completion. A locked object remains locked until the log entries indicate every intent step as complete. Different computing devices can unlock a locked object by executing any incomplete steps of an intent associated with the locked object.

Abstract: A virtual machine monitor (VMM) is configured to enforce deterministic execution of virtual machines in a multiprocessor machine. The VMM is configured to ensure that any communication by physical processors via shared memory is deterministic. When such VMMs are implemented in a distributed environment of multiprocessor machines coupled via a logical communication link, non-deterministic server applications running on virtual machines using the VMM may be replicated.

Abstract: Techniques for employing a decentralized sleep management service are described herein. In some instances, each computing device of a group of computing devices periodically shares information about itself with each other computing device of the group. With this information, each computing device within the group that is awake and capable of managing other devices selects a subset of devices to probe. The devices then probe this subset to determine whether the probed devices are asleep. In response to identifying a sleeping device, the probing device takes over management of the sleeping device. Managing the sleeping device involves informing other devices of the group that the sleeping device is being managed, in addition to monitoring requests for services on the sleeping device. In response to receiving a valid request for a service hosted by the sleeping device, the managing device awakens the sleeping device and ceases managing the now-woken device.

Abstract: Techniques for leveraging legacy code to deploy native-code desktop applications over a network (e.g., the Web) are described herein. These techniques include executing an application written in native code within a memory region that hardware of a computing device enforces. For instance, page-protection hardware (e.g., a memory management unit) or segmentation hardware may protect this region of memory in which the application executes. The techniques may also provide a narrow system call interface out of this memory region by dynamically enforcing system calls made by the application. Furthermore, these techniques may enable a browser of the computing device to function as an operating system for the native-code application. These techniques thus allow for execution of native-code applications on a browser of a computing device and, hence, over the Web in a resource-efficient manner and without sacrificing security of the computing device.

Abstract: Techniques for leveraging legacy code to deploy native-code desktop applications over a network (e.g., the Web) are described herein. These techniques include executing an application written in native code within a memory region that hardware of a computing device enforces. For instance, page-protection hardware (e.g., a memory management unit) or segmentation hardware may protect this region of memory in which the application executes. The techniques may also provide a narrow system call interface out of this memory region by dynamically enforcing system calls made by the application. Furthermore, these techniques may enable a browser of the computing device to function as an operating system for the native-code application. These techniques thus allow for execution of native-code applications on a browser of a computing device and, hence, over the Web in a resource-efficient manner and without sacrificing security of the computing device.

Abstract: Techniques for employing a decentralized sleep management service are described herein. In some instances, each computing device of a group of computing devices periodically shares information about itself with each other computing device of the group. With this information, each computing device within the group that is awake and capable of managing other devices selects a subset of devices to probe. The devices then probe this subset to determine whether the probed devices are asleep. In response to identifying a sleeping device, the probing device takes over management of the sleeping device. Managing the sleeping device involves informing other devices of the group that the sleeping device is being managed, in addition to monitoring requests for services on the sleeping device. In response to receiving a valid request for a service hosted by the sleeping device, the managing device awakens the sleeping device and ceases managing the now-woken device.

Abstract: Software code of a software system (e.g., a software stack) may be verified as conforming to a specification. A high-level language implementation of the software system may be compiled using a compiler to create an assembly language implementation. A high-level specification corresponding to the software system may be translated to a low-level specification. A verifier may verify that the assembly language implementation functionally conforms to properties described in the low-level specification. In this way, the software system (e.g., a complete software system that includes an operating system, device driver(s), a software library, and one or more applications) may be verified at a low level (e.g., assembly language level).

Abstract: Techniques for utilizing trusted hardware components for mitigating the effects of equivocation amongst participant computing devices of a distributed system are described herein. For instance, a distributed system employing a byzantine-fault-resilient protocol—that is, a protocol intended to mitigate (e.g., tolerate, detect, isolate, etc.) the effects of byzantine faults—may employ the techniques. To do so, the techniques may utilize a trusted hardware component comprising a non-decreasing counter and a key. This hardware component may be “trusted” in that the respective participant computing device cannot modify or observe the contents of the component in any manner other than according to the prescribed procedures, as described herein. Furthermore, the trusted hardware component may couple to the participant computing device in any suitable manner, such as via a universal serial bus (USB) connection or the like.

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.