Microsoft Technology Licensing, LLC

Jacob Rubin Lorch

John R Douceur

Jonathan Ryan Howell

Bryan Jeffrey Parno

Jeremy Eric Elson

Brian Don Zill

Jitendra Dattatraya Padhye

David Alexander Molnar

Chris Hawblitzel

Thomas Moscibroda

Parveen Kumar Patel

Jiahe Helen Wang

Aaron William Ogus

Cheng Huang

Lidong Zhou

Barry Clayton Bond

Ronnie Chaiken

Stuart Schechter

Carlos Garcia Jurado Suarez

Michael P Calligaro

Richard Lloyd Hughes

Srinath Setty

Siddhartha Sen

Jinglei Ren

Randall C Wood

Jeffrey Anson Pang

Frank Christopher Uyeda

Alastair Wolman

Yi-Min Wang

Atul Adya

Josh D Benaloh

William J Bolosky

Cristian Diaconu

Sharad Agarwal

Eric P Traut

Edmund Bernard Nightingale

Oliver H Foehr

Stefan Saroiu

Sergey M Yekhanin

Garret Buban

Leslie B Lamport

Weidong Cui

Chad E Verbowski

James Wiliamson Mickens

Joshua Stanley Allen

Bolin Ding

Karthick Krishnamoorthy

Helen Jiahe Wang

Melissa Erin Chase

Rogerio Ramos

Srinath T V Setty

Olga Ohrimenko

Janardhan Dattatreya Kulkarni

Harsha Prasad Nori

Jieqing Wang

Peng Huang

David M Levin

Christopher Stephen Frederick Smowton

Wenbiao Xing

Wei Wan

Fayssal Martani

Li Chen

Daekyeong Moon

Samuel King

Mauricio David Zaragoza Ibarra

Bryan Parno

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.

Decentralized sleep management

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.

Intents and locks with intent

This document relates to hardware protection of differential privacy techniques. One example obtains multiple instances of encrypted telemetry data within a secure enclave and processes the encrypted telemetry data to obtain multiple instances of unencrypted telemetry data. The example also processes, within the secure enclave, the multiple instances of unencrypted telemetry data to obtain a perturbed aggregate. The example also releases the perturbed aggregate from the secure enclave.

Hardware protection for differential privacy

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.

Statelessly populating data stream into successive files

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.

Executing native-code applications in a browser

A system includes determination of a plurality of meta-copysets of a plurality of storage devices, each of the meta-copysets including a first number of storage devices, determination of a first copyset of a second number of storage devices from a first one of the meta-copysets, where the second number is less than the first number, storage of first data in a fault-tolerant format using the first copyset, determination to migrate the first data from a first storage device of the first copyset, and, in response to the determination to migrate the first data, determine a second copyset of the second number of storage devices including a storage device from the first meta-copyset which is not in the first copyset, and the storage devices of the first copyset except for the first storage device of the first copyset and storage of the first data in a fault-tolerant format using the second copyset.

Meta-copysets for fault-tolerant data storage

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.

Performing scalable, causally consistent reads using a logical wall clock

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.

End-to-end security for hardware running verified software

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.

Enforcing deterministic execution of threads of guest operating systems running in a virtual machine hosted on a multiprocessor machine

Various technologies pertaining to authenticating a password in a manner that prevents offline dictionary attacks are described. A protected module, which can be a hardware security module, a trusted platform module, or the like, is in communication with an authentication server. The protected module comprises a key that is restricted to the protected module. The key is employed in connection with authenticating the password on the protected module.

Utilization of a protected module to prevent offline dictionary attacks

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).

Automated verification of a software system

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&#x2014;that is, a protocol intended to mitigate (e.g., tolerate, detect, isolate, etc.) the effects of byzantine faults&#x2014;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.

Trusted hardware component for distributed systems

Growing community of inventors

Bellevue, WA, United States of America

Jacob Rubin Lorch