Microsoft Technology Licensing, LLC

Frederick Justus Smith

Hari R Pulapaka

Benjamin M Schultz

Yousef A Khalidi

Giridhar Viswanathan

Madhusudhan Talluri

Margarit Simeonov Chenchev

Mehmet Iyigun

John Andrew Starks

Amber Tianqi Guo

Michael Bishop Ebersol

Jeff L Havens

Jonathan David Wiswall

Balaji Balasubramanyan

Charles Glenn Jeffries

Ankit Srivastava

Pavel Anatolievich Dournov

John Carroll Gordon

Anil A Ingle

Matthew David Kurjanowicz

Ling Tony Chen

Ravinder S Thind

Jose Bernabeu-Auban

Lars Reuther

Gerardo Diaz Cuellar

Scott Daniel Anderson

Jonathan D Schwartz

Eugene Seichi Lin

David John Linsley

David Bradley Probert, Jr

Poornananda R Gaddehosur

Ivan Dimitrov Pashov

Daniel Vasquez Lopez

Kinshumann Kinshumann

Richard O Wolcott

Jonathan De Marco

Paul Bozzay

Deepu Chandy Thomas

Narasimhan Ramasubramanian

Kyle Thomas Brady

David Guy Weston

Maxwell Christopher Renke

Morakinyo Korede Olugbade

Jeffrey Lee Havens

Ali Hajy

Nived Kalappuraikal Sivadas

Raphael Gianotti Serrano Dos Santo

Taylor James Stark

John Joseph Richardson

Jason T Cobb

Matthew Kerner

Vamshidhar Radha Kommineni

Stephen E Bensley

Abhinav Mishra

Yanan Zhang

Kinshumann

Bryan R Born

Navin Narayan Pai

Axel Rietschin

Oleg Kagan

Ian James McCarty

JianMing M Zhou

Prakhar Srivastava

Yi Lin

Peteris Ledins

Vikram Mangalore Rao

Joshua David Ebersol

Jeffrey M Engel

Taylor Stark

Adam Liechty

Jianming Zhou

Charles G Jeffries

Matthew M Kerner

Distribution and management of services in virtual environments is described herein. In one or more implementations, a service distribution and management model is implemented in which system services and applications are seamlessly distributed across multiple containers which each implement a different runtime environment. In one or more implementations, a system for distributing access to services in a host operating system of a computing device includes a host operating system configured to implement a host runtime environment, and one or more services implemented by the host operating system. The system further includes a service control manager configured to enable communication between a client stub of a service implemented in a client runtime environment and a service provider of the service that is implemented in a service runtime environment that is separate from the first client runtime environment.

Distribution and management of services in virtual environments

Computing systems, devices, and methods of dynamic image composition for container deployment are disclosed herein. One example technique includes receiving a request for accessing a file from a container process. In response to receiving the request, the technique includes querying a mapping table corresponding to the container process to locate an entry corresponding to a file identifier of the requested file. The entry also includes data identifying a file location on the storage device from which the requested file is accessible. The technique further includes retrieving a copy of the requested file according to the file location identified by the data in the located entry in the mapping table and providing the retrieved copy of the requested file to the container process, thereby allowing the container process to access the requested file.

Dynamic image composition for container deployment

Techniques of deferred container deployment are disclosed herein. In one embodiment, a method includes receiving, at a computing device, a container image corresponding to the container. The container image includes a first set of files identified by symbolic links individually directed to a file in the host filesystem on the computing device and a second set of files identified by hard links. The method also includes in response to receiving the container image, at the computing device, storing the received container image in a folder of the host filesystem on the computing device without resolving the symbolic links of the first set of the files until runtime of the requested container.

Deferred path resolution during container deployment

Memory is partitioned and isolated in container-based memory enclaves. The container-based memory enclaves have attestable security guarantees. During provisioning of the container-based memory enclaves from a container image, a purported link in the container to a memory address of the enclave is modified to verifiably link to an actual memory address of the host, such as partitioned memory enclave. In some instances, enclave attestation reports can be validated without transmitting corresponding attestation requests to remote attestation services, based on previous attestation of one or more previous container attestation reports from a similar container and without requiring end-to-end attestation between the container and remote attestation service for each new attestation request.

Using secure memory enclaves from the context of process containers

One example technique includes receiving a request for accessing a file from a container process. In response to receiving the request, the technique includes querying a mapping table corresponding to the container process to locate an entry corresponding to a file identifier of the requested file. The entry also includes data identifying a file location on the storage device from which the requested file is accessible. The technique further includes retrieving a copy of the requested file according to the file location identified by the data in the located entry in the mapping table and providing the retrieved copy of the requested file to the container process, thereby allowing the container process to access the requested file.

Technologies are described for selective persistence of data utilized by software containers. A configuration policy is defined that includes data that specifies one or more data stores for which data is not to be persisted following accesses to a software container and one or more data stores for which data is to be persisted following accesses to the software container. When the software container is first accessed, the data stores identified in the configuration policy are attached to the software container. Upon a subsequent access to the container, such as at the conclusion of a user session or upon destruction of the container, the data in the attached data stores is persisted or deleted based upon the configuration policy. When the software container is once again accessed, the data store containing the persisted data can be re-attached to the software container.

Selective persistence of data utilized by software containers

Securely performing file operations. A method includes determining a licensing characteristic assigned to a file. When the licensing characteristic assigned to the file meets or exceeds a predetermined licensing condition, then the method includes performing a file operation on the file in a host operating system while preventing the file operation from being performed in the guest operating system. When the licensing characteristic assigned to the file does not meet or exceed the predetermined licensing condition, then the method includes performing the file operation on the file in the guest operating system while preventing the file operation from being performed directly in the host operating system.

Method and system for persisting files

Techniques of migrating containerized software packages between source and destination computing devices are disclosed herein. In one embodiment, a method includes receiving, at a destination device, a request to migrate a source container currently executing on the source device to the destination device. The method also includes synchronizing a list of handles utilized by the source container on the source device between the destination device and the source device and instantiating, in the destination device, a destination container using a copy of an image, a memory snapshot, and the synchronized list of handles of the source container on the source device. Upon completion of instantiating the destination container, the destination device can transmit a remote display output of the application to be surfaced on the source device in place of the local display output generated by the source container.

Container migration in computing systems

A host operating system running on a computing device monitors resource access by an application running in a container that is isolated from the host operating system. In response to detecting resource access by the application, a security event is generated describing malicious activity that occurs from the accessing the resource. This security event is analyzed to determine a threat level of the malicious activity. If the threat level does not satisfy a threat level threshold, the host operating system allows the application to continue accessing resources and continues to monitor resource access. When the threat level satisfies the threat level threshold, the operating system takes corrective action to prevent the malicious activity from spreading beyond the isolated container. Through the use of security events, the host operating system is protected from even kernel-level attacks without using resources required to run anti-virus software in the isolated container.

Isolated container event monitoring

Securely performing file operations. A method includes determining a trust characteristic assigned to a file. When the trust characteristic assigned to the file meets or exceeds a predetermined trust condition, then the method includes performing a file operation on the file in a host operating system while preventing the file operation from being performed in the container operating system. When the trust characteristic assigned to the file does not meet or exceed the predetermined trust condition, then the method includes performing the file operation on the file in the container operating system while preventing the file operation from being performed directly in the host operating system.

Method and system for persisting untrusted files

A host operating system running on a computing device monitors network communications for the computing device to identify network resources that are requested by the computing device. The host operating system compares requested network resources against security policies to determine if the requested network resources are trusted. When an untrusted network resource is identified, the host operating system accesses the untrusted network resource within a container that is isolated from the host operating system kernel using techniques discussed herein. By restricting access to untrusted network resources to isolated containers, the host operating system is protected from even kernel-level attacks or infections that may result from an untrusted network resource.

Hardware-based virtualized security isolation

Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Securing virtual execution environments

Growing community of inventors

Redmond, WA, United States of America

Frederick Justus Smith