Microsoft Technology Licensing, LLC

Jared Porter Parsons

John Joseph Duffy

Alexander Daniel Bromfield

Mads Torgersen

Krzysztof J Cwalina

Michael Sinz

Stephen Harris Toub

Matthew J Warren

David N Schach

Peter H Golde

Aleksey V Tsingauz

Neal M Gafter

Julien Couvreur

Karen Liu

Renaud Paquay

Richard Steele Gibson

Martin Taillefer

Avner Y Aharoni

David Charles Wrighton

Jan Kotas

Michael Barnett

Jason Shaver

Tomas Matousek

Kevin Pilch-Bisson

David M Fowler

Jobst-Immo Landwerth

G Shon Katzenberger

David Allen Bartolomeo

Kevin Andrew Pilch

Christopher Sienkiewicz

Andrew Spenser Gocke

Aleksandra Nadia Culver

Colin Stebbins Gordon

Claire Novotny

Software provenance validation reports whether a validation binary matches the source code, resources, and other parts, as well as the compiler, runtime, operating system, and other context, which is specified in a provenance manifest for a release binary. Part context checksums, software versions, tool parameters, and other aspects of a build are checked. Certification signatures, timestamps, certain version differences, source code locations, and other data may be ignored for validation purposes. A provenance manifest may include other provenance manifests, including binary rewrite manifests. The provenance manifest may be stored in a debugger file with symbol information, or stored separately. Partial matches may be reported, with details of what matches or does not match. After provenance of a binary is validated, the binary's source code can be analyzed for vulnerabilities, thereby enhancing software supply chain security.

Software provenance validation

Utilizing role types that extend underlying types. Within a program definition, a computer system identifies a statement assigning an object of an underlying type to a role type that extends the underlying type. The underlying type implements a first interface, and the role type implements a second interface. Based on the role type extending the underlying type, the computer system assigns the object of the underlying type to the role type. Based on assigning the object of the underlying type to the role type, the role type is usable to interact with the object of the underlying type using both the first interface and the second interface.

Runtime support for role types that extend underlying types

Improved compilers recognize interception declarations in source code, and emit code that replaces invocations of specified artifacts with invocations of specified interceptors instead. Source generators proactively modify program behavior in arbitrary desired ways without introducing hidden security violations and without requiring edits by the program's developers. Interception declarations are visible in source code and development tools. In some cases, different invocations of a particular method at respective locations are intercepted by different replacement methods. Replacement methods have identical signatures, or are otherwise compatible. Some interceptors specify optional parameters. Method calls, field accesses, and property calls may be intercepted. Work to modify program behavior is moved in the program lifecycle from runtime to compile time, thus improving runtime performance and eliminating JIT compilation security risks.

Member invocation declarative interception

Efficient immutable syntax representation with parent pointers under incremental change is enabled by creating a data structure comprising at least one tree structure that allows both upward and downward references in the tree and a tree structure that is immutable (read-only), and allows parts of itself to be re-used in other data structures. The data structure described enables tools to search and target particular sub trees. The fragment of the tree representing the targeted sub tree is produced as it is used. The rest of the tree is not produced. The read-only tree retains relative information, allowing it to be reassembled and shared.

Efficient immutable syntax representation with incremental change

The annotation of a returned reference from an executable component to signify that there are no external references to the particular object graph referenced by the returned reference. If either 1) there are no input arguments to the executable component or 2) each input argument is either immutable or represents an object graph that has no external mutable references pointing into the object graph, and no internal mutable references that reference external objects, the particular attribute is assigned to the returned reference. Accordingly, if the returned reference is writable (as determined by evaluating the declaration code or the call code for the executable component), the returned reference is free to have whatever access permissions assigned to it, and may also be assigned to an isolated memory location, though such assignments will cause the returned reference to lose the particular attribute.

Reference attribute annotation signifying no external reference

A language extension that advances safety in system programming in that an entire type may be declared to be immutable in the case in which all instances of that type are immutable. The immutable type declaration automatically causes any instances of that type to be treated as immutable, and automatically causes all directly or indirectly reachable members (e.g., fields, methods, properties) of the instance to also be treated as immutable. Furthermore, any construction time reference that allows for field assignment of the instance is not permitted to survive beyond the point at which the instance becomes accessible to its creator. Accordingly, this instance, and any other instance of that same type, will be immutable from the very time of construction. The ability to classify all such instances as immutable is beneficial as the immutable characteristic permits actions that normally would not be allowed due to resource access safety.

Resource access safety through immutable object types

A front-end compiler compiles source code into intermediate code, that may later be compiled into binary code. The source code defines an execution scope and includes a contract. When a contract is encountered at runtime of an execution scope, further execution of that execution scope is conditioned on whether a predicate associated with the contract is true. The front-end compiler operates so as to preserve the contract so that the contract continues to be semantically structured such that the predicate may be removed from the intermediate language code. The contract may thus continue to be understood by semantic analysis of the contract. Thus, the predicate may be understood by static analysis tools that operate on the intermediate code.

Operating system support for contracts

The type definition of particular types such that different portions of the corresponding object graph may have different permissions assigned to those portions during instantiation. This allows structured permissions to be applied to instantiations of the object graphs of those defined types, allowing fine grained control over what access permissions are enforced against which portions of the object graph. In some embodiments, different instantiations of the object graph may apply permissions differently.

Object graph partial immutability and isolation enforcement

System and method to ensure resource access safety with immutable object types

Growing community of inventors

Kirkland, WA, United States of America

Jared Porter Parsons