1. Automated and Modular Refinement Reasoning for Concurrent Programs Collaborators: Chris Hawblitzel (Microsoft) Erez Petrank (Technion) Serdar Tasiran (Koc University) Shaz Qadeer

2. NDA. Microsoft Confidential. Verified Garbage Collector Verified Threads Verified Interrupt Handlers Verified Device Interface Verified Startup x86 Hardware, Network, PCI, TPM Verified Boot 2 Small Operating System (C#) Verify safety & correctness with Boogie/Z3 “every assembly language instruction checked for safety” Verve: a verifiably safe OS (Yang- Hawblitzel 10)

3. An Ironclad app guarantees to remote parties that every instruction it executes adheres to a high-level security spec. 3 My password will never leak I can run full SQL and the cloud learns nothing

4. Goal: achieve end-to-end security Use small trusted computing base (TCB) — thousands of lines of spec, not millions of lines of code Make approach feasible for use by system and application developers Show developers how to achieve correctness without testing Approach: Combine cryptography, secure hardware, and formal code verification Push scale of formal verification tools to fully encompass large systems 4 Ironclad project (MSR OS Group)

5. NDA. Microsoft Confidential. Ironclad apps atop Verve Verified Garbage Collector Verified Threads Verified Interrupt Handlers Verified Device Interface Verified Startup x86 Hardware, Network, PCI, TPM Notary Verified Boot Bits & ArraysMath Big Integers RSA Enc + Sig SHA Hash TPM DriverNet Driver Ethernet UDP/IP Password Vault 5 DiffPriv DB

6. Verve and concurrency Provides threads No mechanism to reason about them Difficult to provide any assurance beyond memory safety Verve boots on a single core Stop-the-world garbage collector Unacceptable multi-core performance

7. Goal of our work A scalable automated verifier for reasoning about low-level concurrency A verified concurrent garbage collector

8. Refining concurrent programs Atomic actions as specifications Explicit non-interference (ala Owicki-Gries and Jones) Linear resources providing free invariants Verification works for me only when I start small. -Chris Hawblitzel

9. Garbage collector implementation Extends Dijkstra et al. 78 multiple parallel mutators no read barrier fast write barrier Features Mark/Sweep/Idle phases separated by barriers Mutator cooperates with collector Barrier for atomic root scan

10. Garbage collector specification memAbs : [obj][fld]obj// Heap rootAbs : [idx]obj// Roots (stack, registers) allocSet: [obj]bool// Allocated objects

11. Garbage collector verification Simple high-level specification refined down individual instructions load, store, CAS, atomic increment/decrement Six levels of refinement 2100 lines of code and specification 6 min and 2GB memory on a modern Windows machine Simplifying assumptions Allocator is naïve (sequential search for free space) All objects have the same number of fields Sequentially consistent execution

12. Future work Verify under TSO Improve allocator performance Incorporate variable-size objects Extract executable code and plug into Verve