Automated and Modular Refinement Reasoning
for Concurrent Programs
Shaz Qadeer
Collaborators:
Chris Hawblitzel (Microsoft)
Erez Petrank (Technion)
Serdar Tasiran (Koc University)
Verve: a verifiably safe OS (Yang-Hawblitzel 10)
Small Operating System
(C#)
“every assembly
language instruction
checked for safety”
Verified
Garbage
Collector
Verified
Threads
Verified
Interrupt
Handlers
Verified
Device
Interface
Verified
Startup
Verified Boot
x86 Hardware, Network, PCI, TPM
Verify
safety &
correctness
with
Boogie/Z3
2
NDA. Microsoft Confidential.
An Ironclad app guarantees to remote parties
that every instruction it executes adheres to a
high-level security spec.
I can run full SQL and the
My password will never leak
cloud learns nothing
3
Ironclad project (MSR OS Group)
• 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 apps atop Verve
Notary
Password Vault
DiffPriv DB
RSA Enc + Sig
UDP/IP
SHA Hash
Big Integers
Ethernet
Bits & Arrays
Math
Verified
Garbage
Collector
Verified
Threads
Verified
Interrupt
Handlers
TPM Driver
Net Driver
Verified
Device
Interface
Verified
Startup
Verified Boot
x86 Hardware, Network, PCI, TPM
5
NDA. Microsoft Confidential.
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
Goal of our work
• A scalable automated verifier for reasoning about low-level
concurrency
• A verified concurrent garbage collector
Refining concurrent programs
Verification works for me only when I start small.
-Chris Hawblitzel
• Atomic actions as specifications
• Explicit non-interference (ala Owicki-Gries and Jones)
• Linear resources providing free invariants
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
Garbage collector specification
memAbs : [obj][fld]obj
// Heap
rootAbs : [idx]obj
// Roots (stack, registers)
allocSet: [obj]bool
// Allocated objects
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
Future work
• Verify under TSO
• Improve allocator performance
• Incorporate variable-size objects
• Extract executable code and plug into Verve