Verifying Practical Garbage Collectors Virtual

Total Page:16

File Type:pdf, Size:1020Kb

Verifying Practical Garbage Collectors Virtual Verifying Practical Garbage Collectors Chris Hawblitzel Joint work with Erez Petrank (Technion) 1/27 Virtual machines for languages Java bytecode / .NET bytecode / JavaScript / ActionScript Virtual Machine compiler libraries run‐time system exceptio garbage concurrenc x86 n collector y handling 2/27 Virtual machine vulnerabilities Opera JavaScript Pointer Dereference Lets Microsoft Security Bulletin MS07‐040 ‐ Critical Remote Users Execute Arbitrary Code Vulnerabilities in .NET Framework Could Allow Original Entry Date: Aug 15 2007 Remote Code Execution A remote user can create specially crafted Published: July 10, 2007 JavaScript that, when loaded by the target ... user, will make a virtual function call on an What causes the vulnerability? invalid pointer to trigger a memory An unchecked buffer in the .NET Framework 2.0 dereference error and execute arbitrary JIT Compiler service within the .NET Framework. code on the target system. From: Apple Product Security Mozilla Firefox Bug in JavaScript Garbage Date: Fri, 11 Jul 2008 Collector Lets Remote Users Deny Service ... Advisory: Mozilla Foundation Security Advisory Available for: iPhone v1.0 through Date: Apr 16 2008 v1.1.4,iPod touch v1.1 through v1.1.4 A remote user can create specially crafted HTML Description: A memory corruption issue that, when loaded by the target user, will trigger exists in JavaScriptCore's handling of runtime a flaw in the JavaScript garbage collector code garbage collection. Visiting a maliciously and cause the target user's browser to crash. ... crafted website may lead to an unexpected The vendor indicates that similar crashes have application termination or arbitrary code been exploitable in the past, so arbitrary code execution. This update addresses the issue execution may be possible... through improved garbage collection. 3/27 Outline • Virtual machines, vulnerabilities • Proof‐carrying code – Goals: • verify properties of compiler output (e.g. type safety) • verify properties of run‐time system (e.g. correctness) • Simple verified GC • Practical verified GCs 4/27 Proof‐carrying code (Necula, Lee 1996) Java bytecode / .NET bytecode / JavaScript / ActionScript Virtual Machine compiler libraries run‐time system exceptio garbage concurrenc x86 n collector y proof handlingproof proof proof Verifier 5/27 Type‐preserving compilation in Bartok CIL (.NET bytecode) Bartok Compiler (~200,000 LOC) Optimizations: copy propagation, constant propagation,propagation, constant folding, HIR types CSE,CSE, dead‐code elimination, loop‐ invariant removal, loop rotation, inlining,inlining, tree shaking, array bounds check elimination (ABCD, induction MIR types var),var), reverse CSE for LEA instruction, peephole optimizations,optimizations, elimination of redundant CC ops, optimize boolean test and branch, floating point stack LIR types optimizations, convert “ADD” to “LEA”, graph‐coloring register allocation,allocation, code layout, ... x86 types “Typed assembly language” (Morrisett et al 1998) 6/27 Typed output from Bartok B1: {eax:int, ebx:int} cmp eax, 5 jne B3 B2: B3: mov ecx, eax mov ecx, ebx jmp B1 add ecx, 1 B4: {ecx:int} add ecx, 1 … 7/27 Array bounds safety in Bartok CIL (.NET bytecode) Bartok Compiler (~200,000 LOC) Optimizations: copy propagation, constant propagation,propagation, constant folding, HIR types CSE,CSE, dead‐code elimination, loop‐ invariant removal, loop rotation, inlining,inlining, tree shaking, array bounds unsafe check elimination (ABCD, induction MIR types proofs var),var), reverse CSE for LEA instruction, peephole optimizations,optimizations, elimination of redundant CC ops, optimize boolean test and branch, floating point stack LIR types proofs optimizations, convert “ADD” to “LEA”, graph‐coloring register allocation,allocation, code layout, ... x86 types proofs 8/27 A bug in Bartok: ABCD void F(int[] arr, int i) { if (i <= arr.Length) { counterexample: // i ≤ arr.Length i = ‐231 int j = i ‐ 1; j = 231 ‐ 1 // j < i ≤ arr.Length j > i if (j >= 0) { // 0 ≤ j < i ≤ arr.Length // no bounds check required! vulnerability: arr[j]++; address = &(arr[0]) + 4*j } = &(arr[0]) + 4*(231 ‐ 1) } = &(arr[0]) ‐ 4 } 9/27 Outline • Virtual machines, vulnerabilities • Proof‐carrying code • Simple verified GC – Program verification with Boogie/Coq, Boogie/Z3 – Miniature mark‐sweep collector – Integers, bit vectors, arrays, quantifiers • Practical verified GCs 10/27 Program verification (demo) 11/27 Mark‐sweep and copying collectors abstract A BC graph (root) mark‐sweep copying from copying to A A A C C B B B 12/27 Garbage collector properties • safety: gc does no harm – graph isomorphism • concrete graph represents abstract graph verified (McCreight, Shao et al 2007) • effectiveness – after gc, unreachable objects reclaimed • termination not • efficiency verified 13/27 Proving safety abstract $AbsMem A BC graph (root) $toAbs $toAbs concrete Mem graph A B procedure GarbageCollect() requires MutatorInv(root, Color, $toAbs, $AbsMem, Mem); functionmodifies MutatorInv(...) Mem, Color, $toAbs; returns (bool) { ensuresWellFormed($toAbs) MutatorInv(root, && Color, memAddr(root) $toAbs, $AbsMem, && $toAbs[root] Mem); != NO_ABS &&... (forall i:int::{T(i)} T(i) && memAddr(i) ==> ObjInv(i, $toAbs, $AbsMem, Mem)) {&& (forall i:int::{T(i)} T(i) && memAddr(i) ==> White(Color[i])) &&... call (forall Mark(root); i:int::{T(i)} ...T(i) && memAddr(i) ==> ($toAbs[i]==NO_ABS <==> Unalloc(Color[i])))} functioncall Sweep(); ObjInv(...) returns (bool) { $toAbs[i] != NO_ABS ==> } ... $toAbs[Mem[i, field]] != NO_ABS ... ... $toAbs[Mem[i, field]] == $AbsMem[$toAbs[i], field] ... } 14/27 Verifying Mark procedure Mark(ptr:int) requires GcInv(Color, $toAbs, $AbsMem, Mem); requires memAddr(ptr) && T(ptr); requires $toAbs[ptr] != NO_ABS; Mark creates no new gray, white objects modifies Color; ensures GcInv(Color, $toAbs, $AbsMem, Mem); ensures (forall i:int::{T(i)} T(i) && !Black(Color[i]) ==> Color[i] == old(Color)[i]); ensures !White(Color[ptr]); { if (White(Color[ptr])) { Color[ptr] := 2; // make gray call Mark(Mem[ptr,0]); call Mark(Mem[ptr,1]); Color[ptr] := 3; // make black } } 15/27 Verifying Mark procedure Mark(ptr:int) requires GcInv(Color, $toAbs, $AbsMem, Mem); requires memAddr(ptr) && T(ptr); requires $toAbs[ptr] != NO_ABS; modifies Color; ensures GcInv(Color, $toAbs, $AbsMem, Mem); ensures (forall i:int::{T(i)} T(i) && !Black(Color[i]) ==> Color[i] == old(Color)[i]); ensures !White(Color[ptr]); { if (White(Color[ptr])) { A Color[ptr] := 2; // make gray B call Mark(Mem[ptr,0]); call Mark(Mem[ptr,1]); Color[ptr] := 3; // make black } A B } forallforall i:int i:int::{T(i)}::{T(i)} T(i) T(i) && && memAddr(i) memAddr(i) ==> ==> Black(Color[i]) ObjInv(i, $toAbs, ==> !White(Color[Mem[i,field]]$AbsMem, Mem) 16/27 Integers, bit vectors, arrays (decidable) procedure Mark(ptr:int) memAddr(i) <==> memLo <= i && i < memHi requires GcInv(Color, $toAbs, $AbsMem, Mem); requires memAddr(ptr) && T(ptr); requires $toAbs[ptr] != NO_ABS; modifies Color; ensures GcInv(Color, $toAbs, $AbsMem, Mem); ensures (forall i:int::{T(i)} T(i) && !Black(Color[i]) ==> Color[i] == old(Color)[i]); ensures !White(Color[ptr]); { if (White(Color[ptr])) { Color[ptr] := 2; // make gray (equivalent to “Color := Color[ptr := 2];” call Mark(Mem[ptr,0]); call Mark(Mem[ptr,1]); booleanColor[ptr] expressions := 3; // makee black ::= true | false | x | !e | e && e | e ==> e | ... linear} integer arithmetic e ::= ... | ‐2 | ‐1 | 0 | 1 | 2 | e + e | e –e | e <= e | ... } bit vector arithmetic e ::= ... | e & e | e << e | ... arrays e ::= ... | e[e] | e[e := e] 17/27 Quantifiers (undecidable) procedure Mark(ptr:int) requires GcInv(Color, $toAbs, $AbsMem, Mem); requires memAddr(ptr) && T(ptr); requires $toAbs[ptr] != NO_ABS; explicit introductions of T(...) modifies Color; to provoke quantifier instantiations ensures GcInv(Color, $toAbs, $AbsMem, Mem); ensures (forall i:int::{T(i)} T(i) && !Black(Color[i]) ==> Color[i] == old(Color)[i]); ensures !White(Color[ptr]); “trigger” quantifier instantiation { i =e when T(e) seen if (White(Color[ptr])) { Color[ptr] := 2; // make gray (equivalent to “Color := Color[ptr := 2];” call Mark(Mem[ptr,0]); T is a dummy function: call Mark(Mem[ptr,1]); Color[ptr] := 3; // make black T(e) <==> true } } 18/27 Outline • Virtual machines, vulnerabilities • Proof‐carrying code • Simple verified GC • Practical verified GCs – Mark‐sweep collector • Mark stack • Table of color bits (2 bits per color) • Allocate small objects from cache • Allocate large objects, caches from free list – Copying collector • Simple 2‐space Cheney queue algorithm • Not generational 19/27 Mutator‐GC interface The mutator (the program) calls these procedures: ¾ Initialize() ¾ read($ptr:int, $field:int) prove that it’s safe to read/write ¾ write($ptr:int, $field:int, $val:int) (mutator then performs read/write) ¾ AllocateObject(VTable vtable) ¾ AllocateString(int stringLength) ¾ AllocateVector(VTable vtable, int numElems) ¾ AllocateArray(VTable vtable, int numDims, int numElems) (Note: we define a field to be an aligned, 4‐byte word) 20/27 Object layouts (multi‐dimensional) Class object String Vector Array preheader preheader preheader preheader vtable vtable vtable vtable data field numChars numElems numDims (private) elements numElems data field char char base/length elements char char base/length ... elements tag(vtable) == ?STRING_TAG ==> numFields(abs) >= 4 && 4 * numFields(abs) == pad(16 + 2 * numChars) ... elements 21/27 VTables and GC information Class object VTable preheader vtable data field gc info data
Recommended publications
  • In This Issue
    FALL 2019 IN THIS ISSUE JONATHAN BISS CELEBRATING BEETHOVEN: PART I November 5 DANISH STRING QUARTET November 7 PILOBOLUS COME TO YOUR SENSES November 14–16 GABRIEL KAHANE November 23 MFA IN Fall 2019 | Volume 16, No. 2 ARTS LEADERSHIP FEATURE In This Issue Feature 3 ‘Indecent,’ or What it Means to Create Queer Jewish Theatre in Seattle Dialogue 9 Meet the Host of Tiny Tots Concert Series 13 We’re Celebrating 50 Years Empowering a new wave of Arts, Culture and Community of socially responsible Intermission Brain arts professionals Transmission 12 Test yourself with our Online and in-person trivia quiz! information sessions Upcoming Events seattleu.edu/artsleaderhip/graduate 15 Fall 2019 PAUL HEPPNER President Encore Stages is an Encore arts MIKE HATHAWAY Senior Vice President program that features stories Encore Ad 8-27-19.indd 1 8/27/19 1:42 PM KAJSA PUCKETT Vice President, about our local arts community Sales & Marketing alongside information about GENAY GENEREUX Accounting & performances. Encore Stages is Office Manager a publication of Encore Media Production Group. We also publish specialty SUSAN PETERSON Vice President, Production publications, including the SIFF JENNIFER SUGDEN Assistant Production Guide and Catalog, Official Seattle Manager ANA ALVIRA, STEVIE VANBRONKHORST Pride Guide, and the Seafair Production Artists and Graphic Designers Commemorative Magazine. Learn more at encorespotlight.com. Sales MARILYN KALLINS, TERRI REED Encore Stages features the San Francisco/Bay Area Account Executives BRIEANNA HANSEN, AMELIA HEPPNER, following organizations: ANN MANNING Seattle Area Account Executives CAROL YIP Sales Coordinator Marketing SHAUN SWICK Senior Designer & Digital Lead CIARA CAYA Marketing Coordinator Encore Media Group 425 North 85th Street • Seattle, WA 98103 800.308.2898 • 206.443.0445 [email protected] encoremediagroup.com Encore Arts Programs and Encore Stages are published monthly by Encore Media Group to serve musical and theatrical events in the Puget Sound and San Francisco Bay Areas.
    [Show full text]
  • Automated and Modular Refinement Reasoning for Concurrent Programs
    Automated and modular refinement reasoning for concurrent programs Chris Hawblitzel Erez Petrank Shaz Qadeer Serdar Tasiran Microsoft Technion Microsoft Ko¸cUniversity Abstract notable successes using the refinement approach in- clude the work of Abrial et al. [2] and the proof of full We present civl, a language and verifier for concur- functional correctness of the seL4 microkernel [37]. rent programs based on automated and modular re- This paper presents the first general and automated finement reasoning. civl supports reasoning about proof system for refinement verification of shared- a concurrent program at many levels of abstraction. memory multithreaded software. Atomic actions in a high-level description are refined We present our verification approach in the context to fine-grain and optimized lower-level implementa- of civl, an idealized concurrent programming lan- tions. A novel combination of automata theoretic guage. In civl, a program is described as a collection and logic-based checks is used to verify refinement. of procedures whose implementation can use the stan- Modular specifications and proof annotations, such dard features such as assignment, conditionals, loops, as location invariants and procedure pre- and post- procedure calls, and thread creation. Each procedure conditions, are specified separately, independently at accesses shared global variables only through invoca- each level in terms of the variables visible at that tions of atomic actions. A subset of the atomic ac- level. We have implemented as an extension to civl tions may be refined by new procedures and a new the language and verifier. We have used boogie civl program is obtained by replacing the invocation of an to refine a realistic concurrent garbage collection al- atomic action by a call to the corresponding proce- gorithm from a simple high-level specification down dure refining the action.
    [Show full text]
  • Proceedings, the 57Th Annual Meeting, 1981
    PROCEEDINGS THE FIFTY-SEVENTH ANNUAL MEETING National Association of Schools of Music NUMBER 70 APRIL 1982 NATIONAL ASSOCIATION OF SCHOOLS OF MUSIC PROCEEDINGS OF THE 57th ANNUAL MEETING Dallas, Texas I98I COPYRIGHT © 1982 ISSN 0190-6615 NATIONAL ASSOCIATION OF SCHOOLS OF MUSIC 11250 ROGER BACON DRIVE, NO. 5, RESTON, VA. 22090 All rights reserved including the right to reproduce this book or parts thereof in any form. CONTENTS Speeches Presented Music, Education, and Music Education Samuel Lipman 1 The Preparation of Professional Musicians—Articulation between Elementary/Secondary and Postsecondary Training: The Role of Competitions Robert Freeman 11 Issues in the Articulation between Elementary/Secondary and Postsecondary Training Kenneth Wendrich 19 Trends and Projections in Music Teacher Placement Charles Lutton 23 Mechanisms for Assisting Young Professionals to Organize Their Approach to the Job Market: What Techniques Should Be Imparted to Graduating Students? Brandon Mehrle 27 The Academy and the Marketplace: Cooperation or Conflict? Joseph W.Polisi 30 "Apples and Oranges:" Office Applications of the Micro Computer." Lowell M. Creitz 34 Microcomputers and Music Learning: The Development of the Illinois State University - Fine Arts Instruction Center, 1977-1981. David L. Shrader and David B. Williams 40 Reaganomics and Arts Legislation Donald Harris 48 Reaganomics and Art Education: Realities, Implications, and Strategies for Survival Frank Tirro 52 Creative Use of Institutional Resources: Summer Programs, Interim Programs, Preparatory Divisions, Radio and Television Programs, and Recordings Ray Robinson 56 Performance Competitions: Relationships to Professional Training and Career Entry Eileen T. Cline 63 Teaching Aesthetics of Music Through Performance Group Experiences David M.Smith 78 An Array of Course Topics for Music in General Education Robert R.
    [Show full text]
  • Inferable Object-Oriented Typed Assembly Language
    Inferable Object-Oriented Typed Assembly Language Ross Tate Juan Chen Chris Hawblitzel University of California, San Diego Microsoft Research Microsoft Research [email protected] [email protected] [email protected] Abstract 1. Introduction A certifying compiler preserves type information through compi- Internet users regularly download and execute safe, untrusted code, lation to assembly language programs, producing typed assembly in the form of Java applets, JavaScript code, Flash scripts, and language (TAL) programs that can be verified for safety indepen- Silverlight programs. In the past, browsers have interpreted much dently so that the compiler does not need to be trusted. There of this code, but the desire for better performance has recently are two challenges for adopting certifying compilation in prac- made just-in-time compilation more common, even for scripting tice. First, requiring every compiler transformation and optimiza- languages. However, compilation poses a security risk: users must tion to preserve types is a large burden on compilers, especially trust the compiler, since a buggy compiler could translate safe when adopting certifying compilation into existing optimizing source code into unsafe assembly language code. Therefore, Nec- non-certifying compilers. Second, type annotations significantly ula and Lee [17] and Morrisett et al. [15] introduced proof-carrying increase the size of assembly language programs. code and typed assembly language (TAL). These technologies an- This paper proposes an alternative to traditional certifying com- notate assembly language with proofs or types that demonstrate the pilers. It presents iTalX, the first inferable TAL type system that safety of the assembly language, so that the user trusts a small proof supports existential types, arrays, interfaces, and stacks.
    [Show full text]
  • 2014 UPTOWN ARTS STROLL PASEO DE LAS ARTES May 29–June 30 | Guide/Guía Celebrating the Arts in Washington Heights and Inwood Honoring: Annette A
    Poster Design: Felipe Galindo 2014 UPTOWN ARTS STROLL PASEO DE LAS ARTES May 29–June 30 | Guide/Guía Celebrating the arts in Washington Heights and Inwood Honoring: Annette A. Aguilar, René De Los Santos, Sky Pape and Janifer Wilson Northern Manhattan Arts Alliance 178 Bennett Avenue, Third Floor - New York, NY 10040 www.artstroll.com | www.nomaanyc.org @NoMAArts | Northern Manhattan Arts Alliance 02 2014 UPTOWN ARTS STROLL KICK-OFF THURSDAY, MAY 29 THE 2014 UPTOWN ARTS STROLL IS FINALLY HERE! ¡LLEGO EL PASEO DE LAS ARTES 2014! Welcome! Northern Manhattan will be, once again, the ¡Bienvenido! La apertura del Paseo se llevara a cabo en center of everything arts related during the month of June. el Parque Highbridge en la Avenida Amsterdam y calle Included among the many activities happening during the 172, en Washington Heights. Este parque histórico fue 2014 Uptown Arts Stroll are art exhibitions, outdoor theatre, bautizado con el nombre “Puente Alto” , en honor al puente dance, music, open studios and much more! The Stroll más antiguo de la ciudad de Nueva York, conocido por la kick- off celebration will be held on Thursday, May 29th from torre Highbridge y sus hermosas vistas del Rio Harlem, 6:00pm-8:30pm at Highbridge Park, Amsterdam Avenue el Puente Washington, los puentes Alexander Hamilton y & West 172nd Street. Landmarked and named after the University Heights, Manhattan y el Bronx. El Highbridge o High Bridge, the city’s oldest standing bridge, Highbridge “Puente Alto” que conecta a Washington Heights con el Park is widely known for its landmarked Highbridge Tower Bronx reabrirá en diciembre del 2014.
    [Show full text]
  • Valor: Efficient, Software-Only Region Conflict Exceptions ∗
    Valor: Efficient, Software-Only Region Conflict Exceptions ∗ Swarnendu Biswas Minjia Zhang Michael D. Bond Brandon Lucia Ohio State University Carnegie Mellon University {biswass,zhanminj,mikebond}@cse.ohio-state.edu [email protected] rtifact A Comple * t * te n * A * te is W E s A e n C l l L o D C S o * * c P u e m s E u O e e n v R t e O o d t a y * s E a * l u d a e t Abstract 1. Introduction Data races complicate programming language semantics, and Data races are a fundamental barrier to providing well- a data race is often a bug. Existing techniques detect data defined programming language specifications and to writing races and define their semantics by detecting conflicts be- correct shared-memory, multithreaded programs. A data race tween synchronization-free regions (SFRs). However, such occurs when two accesses to the same memory location are techniques either modify hardware or slow programs dramat- conflicting—executed by different threads and at least one ically, preventing always-on use today. is a write—and concurrent—not ordered by synchronization This paper describes Valor, a sound, precise, software- operations [4]. only region conflict detection analysis that achieves high Data races can cause programs to exhibit confusing and performance by eliminating the costly analysis on each incorrect behavior. They can lead to sequential consistency read operation that prior approaches require. Valor instead (SC), atomicity, and order violations [42, 54] that may corrupt logs a region’s reads and lazily detects conflicts for logged data, cause a crash, or prevent forward progress [28, 36, 52].
    [Show full text]
  • Inferable Object-Oriented Typed Assembly Language
    Inferable Object-Oriented Typed Assembly Language Ross Tate Juan Chen Chris Hawblitzel University of California, San Diego Microsoft Research Microsoft Research [email protected] [email protected] [email protected] Abstract 1. Introduction A certifying compiler preserves type information through compi- Internet users regularly download and execute safe, untrusted code, lation to assembly language programs, producing typed assembly in the form of Java applets, JavaScript code, Flash scripts, and language (TAL) programs that can be verified for safety indepen- Silverlight programs. In the past, browsers have interpreted much dently so that the compiler does not need to be trusted. There of this code, but the desire for better performance has recently are two challenges for adopting certifying compilation in prac- made just-in-time compilation more common, even for scripting tice. First, requiring every compiler transformation and optimiza- languages. However, compilation poses a security risk: users must tion to preserve types is a large burden on compilers, especially trust the compiler, since a buggy compiler could translate safe when adopting certifying compilation into existing optimizing source code into unsafe assembly language code. Therefore, Nec- non-certifying compilers. Second, type annotations significantly ula and Lee [17] and Morrisett et al. [15] introduced proof-carrying increase the size of assembly language programs. code and typed assembly language (TAL). These technologies an- This paper proposes an alternative to traditional certifying com- notate assembly language with proofs or types that demonstrate the pilers. It presents iTalX, the first inferable TAL type system that safety of the assembly language, so that the user trusts a small proof supports existential types, arrays, interfaces, and stacks.
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 8,629,885 B2 Tzruya Et Al
    USOO8629885B2 (12) United States Patent (10) Patent No.: US 8,629,885 B2 Tzruya et al. (45) Date of Patent: Jan. 14, 2014 (54) SYSTEM, METHOD AND COMPUTER (56) References Cited PROGRAMI PRODUCT FOR DYNAMICALLY IDENTIFYING, SELECTING AND U.S. PATENT DOCUMENTS EXTRACTING GRAPHICAL AND MEDIA 5,687,376 A 11/1997 Celi et al. OBJECTS IN FRAMES OR SCENES 5,737,553 A * 4, 1998 Bartok .......................... 715,764 RENDERED BY A SOFTWARE APPLICATION (Continued) (75) Inventors: Yoav Tzruya, Even Yehuda (IL); Itay Nave, Kfar Hess (IL) FOREIGN PATENT DOCUMENTS (73) Assignee: Exent Technologies, Ltd., Petach-Tikva JP 2001-312286 A 11, 2001 (IL) KR 2005O111581 11, 2005 (*) Notice: Subject to any disclaimer, the term of this (Continued) patent is extended or adjusted under 35 U.S.C. 154(b) by 1421 days. OTHER PUBLICATIONS (21) Appl. No.: 11/588,318 Dr. Daniel E. Lipkie, Steven R. Evans, John K. Newlin, and Robert L. Weissman; Star Graphics: An Object-Oriented Implementation; Jul. (22) Filed: Oct. 27, 2006 1982; ACM; Computer Graphics; vol. 15, No. 3, pp. 115-124.* (65) Prior Publication Data (Continued) US 2007/O126749 A1 Jun. 7, 2007 Primary Examiner — Jeffery A Brier Related U.S. Application Data (74) Attorney, Agent, or Firm — Fiala & Weaver P.L.L.C. (63) Continuation-in-part of application No. 1 1/492,069, (57) ABSTRACT filed on Jul. 25, 2006, now abandoned, which is a continuation-in-part of application No. 1 1/472,454, A technique is described herein for dynamically enhancing filed on Jun. 22, 2006, now Pat. No.
    [Show full text]
  • SMT Solvers in Program Analysis and Verification
    IJCAR 2008 4th International Joint Conference on Automated Reasoning Sydney, Australia, August 10–15, 2008 Tutorial Program SMT Solvers in Program Analysis and Verification Nikolaj Bjørner and Leonardo de Moura T 3 – August 10 8/4/2008 Appetizers SMT solving Applications Applications at Microsoft Research Background Basics, DPLL(), Equality, Arithmetic, Leonardo de Moura and Nikolaj Bjørner DPLL(T), Arrays, Matching Microsoft Research Z3 – An Efficient SMT solver Bits and bytes 0 ((x 1) & x ) x 00100000..00 Numbers x y y x Arrays read( write ( a , i ,4), i ) 4 Records mkpair(,)(,) x y mkpair z u x z Heaps n** n'(,)' m cons a n m n Data-types car( cons ( x , nil )) x Object inheritance BACBCA::: x 2 y f (read(write(a, x,3), y 2) f (y x 1) Arithmetic Arrays Free Functions © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. 1 8/4/2008 SMT solvers are used in several applications:
    [Show full text]
  • Singularity: Rethinking the Software Stack
    Singularity: Rethinking the Software Stack Galen C. Hunt and James R. Larus Microsoft Research Redmond [email protected] ABSTRACT modern operating systems have not evolved to accommodate the Every operating system embodies a collection of design decisions. enormous shift in how computers are used. Many of the decisions behind today’s most popular operating systems have remained unchanged, even as hardware and 1.1 A Journey, not a Destination software have evolved. Operating systems form the foundation of In the Singularity project, we have built a new operating system, a almost every software stack, so inadequacies in present systems new programming language, and new software verification tools. have a pervasive impact. This paper describes the efforts of the The Singularity operating system incorporates a new software Singularity project to re-examine these design choices in light of architecture based on software isolation of processes. Our advances in programming languages and verification tools. programming language, Sing# [8], is an extension of C# that Singularity systems incorporate three key architectural features: provides verifiable, first-class support for OS communication software-isolated processes for protection of programs and system primitives as well as strong support for systems programming and services, contract-based channels for communication, and code factoring. The sound verification tools detect programmer manifest-based programs for verification of system properties. We errors early in the development cycle. describe this foundation in detail and sketch the ongoing research From the beginning, Singularity has been driven by the following in experimental systems that build upon it. question: what would a software platform look like if it was designed from scratch, with the primary goal of improved Keywords dependability and trustworthiness? To this end, we have Operating systems, safe programming languages, program championed three strategies.
    [Show full text]
  • Singularity: Designing BeEr SoWare
    Singularity: Designing Beer So3ware James Larus Microso. Research CAV July 10, 2008 MSR’s Decade of Tools Progress (and Frustra?on) • MSR has researched, developed, and deployed programming tools for 10+ years • Struggle to bring tools to pracFce – incomplete, informal specificaon – unsafe languages (C) – tenuous assumpFons (e.g., code completely known and immutable) • Verificaon and tesFng at a low level – language features and library APIs – persistent quesFon: “are these the right bugs?” • So.ware development is inherently broken – “first we bug the so.ware, then we debug it” • People and organizaon may be more important than bugs and tesFng – (another talk) Singularity Singularity • Microso. Research project with goal of more robust and reliable so.ware Safe • Rethink the so.ware stack Languages (C#) • ArFculated architectural principles – so.ware will fail, system should not – system should be self-describing Verification Tools – verify as many aspects as possible • No single magic bullet Improved OS Architecture – mutually reinforcing improvements to languages and compilers, systems, and tools Singularity Singularity in the News Judging from recent rumours, Unfortunately,that's this what willingness it is preparing to begin with to do.an entirely newEven foundation though isit notwon't located be withinin the WindowsWindows group but 7,in Microsoft’sMicrosoft research is happy arm, where scientiststo talk andabout their “ hereticalMinWin thoughts”—a are safely isolated.slimmed Last down April, Microsoftversion ofpublicly the unveiledWindows the five-year-old core. research It’s even project, willing called “Singularity.”to discus It is nothing its “Singularity” more than a neat project academic—a exercise, microkernel-based not a glimpse of Windows operating 7.
    [Show full text]
  • Australian Chamber Music with Piano
    Australian Chamber Music with Piano Australian Chamber Music with Piano Larry Sitsky THE AUSTRALIAN NATIONAL UNIVERSITY E PRESS E PRESS Published by ANU E Press The Australian National University Canberra ACT 0200, Australia Email: [email protected] This title is also available online at: http://epress.anu.edu.au/ National Library of Australia Cataloguing-in-Publication entry Author: Sitsky, Larry, 1934- Title: Australian chamber music with piano / Larry Sitsky. ISBN: 9781921862403 (pbk.) 9781921862410 (ebook) Notes: Includes bibliographical references. Subjects: Chamber music--Australia--History and criticism. Dewey Number: 785.700924 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying or otherwise, without the prior permission of the publisher. Cover design and layout by ANU E Press Cover image: ANU E Press Printed by Griffin Press This edition © 2011 ANU E Press Contents Acknowledgments . vii Preface . ix Part 1: The First Generation 1 . Composers of Their Time: Early modernists and neo-classicists . 3 2 . Composers Looking Back: Late romantics and the nineteenth-century legacy . 21 3 . Phyllis Campbell (1891–1974) . 45 Fiona Fraser Part 2: The Second Generation 4 . Post–1945 Modernism Arrives in Australia . 55 5 . Retrospective Composers . 101 6 . Pluralism . 123 7 . Sitsky’s Chamber Music . 137 Edward Neeman Part 3: The Third Generation 8 . The Next Wave of Modernism . 161 9 . Maximalism . 183 10 . Pluralism . 187 Part 4: The Fourth Generation 11 . The Fourth Generation . 225 Concluding Remarks . 251 Appendix . 255 v Acknowledgments Many thanks are due to the following.
    [Show full text]