Microsoft Technology Licensing, LLC

Hari R Pulapaka

Benjamin M Schultz

Frederick Justus Smith

Arun Upadhyaya Kishan

Giridhar Viswanathan

Margarit Simeonov Chenchev

Mehmet Iyigun

Alain Franck Gefflaut

Amber Tianqi Guo

Balaji Balasubramanyan

David Bradley Probert, Jr

James A Schwartz, Jr

Ankit Srivastava

John Andrew Starks

Richard K Neves

Michael Bishop Ebersol

Tushar Suresh Sugandhi

Ahmed Saruhan Karademir

Scott Daniel Anderson

David John Linsley

Jonathan David Wiswall

Matthew David Kurjanowicz

Gregory John Colombo

Graham Wong

Richard O Wolcott

Lars Reuther

Gerardo Diaz Cuellar

Ivan Dimitrov Pashov

Nicholas Stephen Judge

Kinshumann Kinshumann

Charles Glenn Jeffries

James Anthony Schwartz, Jr

Neeraj Kumar Singh

Niraj Majmudar

Deepu Chandy Thomas

Alex Bendetov

Axel Rietschin

Navin Narayan Pai

Chase Thomas

Morakinyo Korede Olugbade

Abhijat Singh

Gupta Shubham

Jonathan De Marco

Frederick J Smith, Iv

Paul Bozzay

Maxwell Christopher Renke

Carlos Ernesto Peza Ramirez

Yevgeniy Bak

Neill Michael Clift

John Carroll Gordon

Emily Nicole Wilson

Benjamin Salim Srour

Jeroen Vanturennout

Jon Robert Berry

Ranjib Singh Badh

Pedro Miguel Sequeira De Justo Teixeira

Michael H Krause

Matthew Ryan Miller

Eric Bluestein

Eyal Axelrod

Yuanquan Zhang

Garrett Leischner

Narasimhan Ramasubramanian

Kyle Thomas Brady

Jason Randall Wadsworth

Michael Trevor Pashniak

Zinaida A Pozen

Evan Lincoln Tice

Sudeep Kumar Ghosh

Qian Liu

David Guy Weston

Eric J Horvitz

Christopher A Meek

Ling Tony Chen

Karan Mehra

Michael Richard Fortin

Ravinder S Thind

Scott Chao-Chueh Lee

Asela J Gunawardana

Jonathan D Schwartz

Poornananda R Gaddehosur

Kevin Michael Broas

Harish Srinivasan

Jason Stewart Wohlgemuth

Daniel Vasquez Lopez

Ahmad Bilal

Paul B Koch

John Joseph Richardson

Paresh J Maisuria

Gaurav Jagtiani

Stephen E Bensley

Abhinav Mishra

Yanan Zhang

Kinshumann

Bryan R Born

Abhay Sudhir Ketkar

Ian James McCarty

Christopher Peter Kleynhans

JianMing M Zhou

Binit Ranjan Mishra

Environment type validation can provide a tamper-resistant validation of the computing environment within which the environment type validation is being performed. Such information can then be utilized to perform policy management, which can include omitting verifications in order to facilitate the sharing of policy, such as application licenses, from a host computing environment into a container virtual computing environment. The environment type validation can perform multiple checks, including verification of the encryption infrastructure of the computing environment, verification of code integrity mechanisms of that computing environment, checks for the presence of functionality evidencing a hypervisor, checks for the presence or absence of predetermined system drivers, or other like operating system components or functionality, checks for the activation or deactivation of resource management stacks, and checks for the presence or absence of predetermined values in firmware.

Virtual environment type validation for policy enforcement

A computer system identifies an event from a management system log associated with a first container host. The presence of the event in the management system log is indicative that the first container host identified a fatal system error at the first container host. Based on the event, the computer system determines that a first instance of a container that is provisioned at the first container host has been isolated to the first container host. Based on the first instance of the container having been isolated to the first container host, the computer system instructs a second container host to provision a second instance of the container at the second container host.

Accelerated fatal system error recovery of container host

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

A fine-grain selectable partially privileged container virtual computing environment provides a vehicle by which processes that are directed to modifying specific aspects of a host computing environment can be delivered to, and executed upon, the host computing environment while simultaneously maintaining the advantageous and desirable protections and isolations between the remaining aspects of the host computing environment and the partially privileged container computing environment. Such partial privilege is provided based upon directly or indirectly delineated actions that are allowed to be undertaken on the host computing environment by processes executing within the partially privileged container virtual computing environment and actions which are not allowed. Aspects of the host computing environment operating system, such as the kernel, are extended to interface with container-centric mechanisms to receive information upon which actions can be allowed or denied by the kernel even if the process attempting such actions would otherwise have sufficient privilege.

Partially privileged lightweight virtualization environments

A layered composite boot device, and a corresponding layered composite file system, can be implemented by a boot manager. Requests directed to the layered composite boot device and file system, can be serviced from a primary device and file system that are encapsulated by the layered composite boot device and file system. The primary device and file system can correspond to a virtualized file system within a container environment, thereby enabling changes within the container environment to affect early stages of operating system booting in the container environment. Should such requests not be serviceable from the primary layers, the composite device and file system can comprise secondary layers that can correspond to a container host connection and the host file system, providing fallback to existing data if changes within the container environment were not made, thereby enabling booting to proceed in a traditional manner.

Layered composite boot device and file system for operating system booting in file system virtualization 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

A virtualization partition (VP) is executed by a virtualization layer. The VP contains guest software that executes in isolation within the VP. The guest software has a background task (BT) that needs to be performed in the future. The BT is virtualized by a BT service that executes outside of the VP. The guest software registers the BT, through the virtualization layer, with a BT virtualization service. An event occurs outside of the VP that triggers the BT. The BT virtualization service responds to the event by assuring that the VP is available (executing), and optionally triggers (possibly indirectly) the execution of code in the application.

Virtualized background activations

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.

Enacting a compliance action using an assessment that considers a mix of coldpatches and hotpatches includes identifying a policy defining the compliance condition based on patching status of a software component. A patching state of the software component is determined, including identifying evidence of coldpatched binary file(s) and hotpatch binary file(s) applicable to the software component, and using the evidence to determine whether or not the hotpatch binary file(s) have been applied to a memory image into which an instance of the software component is loaded. Based on the policy and on the patching state of the software component, a compliance action is enacted for the compliance condition. The compliance action includes generating a health report or a health attestation, initiating a patching action, initiating an execution control action, and the like.

System compliance based on a mix of hotpatches and coldpatches

Growing community of inventors

Redmond, WA, United States of America

Hari R Pulapaka