Stuart AllenMark Bickford Robert Constable Richard Eaton Christoph KreitzLori Lorigo Secure software infrastructure Logic Programming Communications Advances in Logical Programming Environments

Build open L ogical P rogramming E nvironment - integrate programming language and logic - share libraries of formalized mathematics - enable cooperation among formal systems - local reflection and code transformations Project goals Application to reliable embedded systems - semantics-based transformation and optimization - high-assurance software components and systems - formal component design

Nuprl LPE - new implementation with open architecture - formal documentation mechanisms - development of class theory - local reflection for weaving aspects Progress - formal design of adaptive systems Application to networked systems - optimization of protocol stacks - compositional protocol verification - formal design of adaptive systems

Cooperating processes Library as persistent database - basis for sharing mathematics Ability to connect to external systems Cooperating inference engines Multiple user interfaces Reflective system structure LPE Architecture

Comments contain references to objects - formal content browsable while reading text Display objects determine term presentation - print representation (screen/LaTeX macros) - suppressing formal parameters - preferences vs. parentheses Formal Documentation Create documentation from formal objects - formal design expertise in “readable” form - screen display, LaTeX articles, HTML documents

Provides expressive type constructs - Union, Intersection, Subtyping, Records, Modules Supports formalization and composition of - Abstract specifications + concrete code of components - Modular verifications   IOA Ocaml (Ensemble) External System Formalizes JVM Java/JVM Ocaml Language Formalized in Nuprl Class theory provides IOA formalisms Formal Class Theory Extends Nuprl’s type theory

Add properties to code MessagePassingwith Total Order FaultTolerant System with Total Order Transform Total Order code to include rejoining & view-change code FaultTolerance Weaving as formal method requires local reflection - thms about semantical effect of syntactical transformations - reasoning about refinement + meta-properties   Weaving and local reflection

Optimize component-based network systems Formal Optimization Fast, abstract, verifiably correct results, speedup factor 3-4 (demo available) Automate with Nuprl LPE Identify Common Case Predicates Component code + CCP -> optimization theorem System composition -> theorem composition Composed theorem -> new system code generate fast-path for common case compress message headers

Incremental through proof inheritance : (A = P)  (A  B = P) A  B intersects : states, actions initial states, transitions Induction: 1. A  I = I 2. B  I = I 3. A.init  B.init  I A  B = I View = view View ETO ETO = total  view Total = total Total Compositional Protocol Verification

Adapt system to suit run-time dynamics - system upgrades - changing conditions (higher security levels, …) - use optimal implementations of components Usually complicated switch spec Building block approach - generic switching protocol constructs hybrid protocols from simpler ones - flexible, easy to prove correct Formal Design of Adaptive Systems Joint work with Robbert Van Renesse, Xiaoming Liu, Ken Birman

Normal mode - forward messages to current protocol - receive messages from current protocol Switching Protocol P1P2 Switching Mode - deliver messages from previous protocol - buffer messages sent in the new protocol Switching Protocols: basic model

What kind of properties will be preserved by switching? In other words, what are the properties of these properties ? Reliability? Total Order?Integrity? Confidentiality? Prioritized Delivery? Virtual Synchrony? propertiesmeta- Inject formal methods at earliest design stage

we proved that six meta-properties are sufficient for protocols to work correctly under a switching protocol switch spec network Using the Nuprl LPE

Formal Model of Communication Communication property - predicate P on traces Trace - List tr of send and receive events Send(p,m) : message p sent by process m Deliver(p,m) : message p received by process m

Confidentiality  q  T. Deliver(q,m)  tr   p  T. Send(p,m)  tr ) Reliability  p,m. Send(p, m)  tr   q. Deliver(q,m)  tr Properties, formalized Integrity (T: set of trusted processes)  q  T. Deliver(q,m)  tr   p  T. Send(p,m)  tr Total order  q 1,q 2,m 1,m 2. Deliver(q 1,m 1 )  tr  Deliver(q 2,m 1 )  tr  Deliver(q 1,m 2 )  tr  Deliver(q 2,m 2 )  tr  Deliver(q 1,m 1 ) < Deliver(q 1, m 2 )  Deliver(q 2,m 1 ) < Deliver(q 2, m 2 )

Expressed by relation R between traces tr u,tr l above and below a protocol layer M (P)   tr u,tr l. P(tr l )  tr l R tr u  P(tr u ) Meta-property Predicate M on properties of protocols   Requires capability for higher order reasoning

Meta-properties for Switching } } Layered Communication Protocol Switching R send-e (tr u,tr l )  tr u = tr [Send(p 1,m 1 ),..,Send(p n,m n )] R async (tr u,tr l )  swap-adjacent(tr l,tr u ) for e 1,e 2 with process(e 1 )  process(e 2 ) R delay (tr u,tr l )  swap-adjacent(tr l,tr u ) for e 1,e 2 with e 1 =Send(p,m 1 )  e 2 = Deliver(p,m 2 ) R safety (tr u,tr l )  tr l  tr u R composable (tr u,tr l 1, tr l 2 )  tr l 1  tr l 2 =[]  interleave(tr u,tr l 1, tr l 2 )  … R memoryless (tr u,tr l )  tr u = tr l - [e | msg(e)  {m 1,..,m n }] Switchable(P)  M safety (P)  …  M composable (P) Asynchrony Safety Delayable Send- enabled Composable Memoryless

Formal design at same pace as “informal” one Verifying Hybrid Protocols  P.  tr u,tr l. switch_invariant(tr u,tr l )  Switchable(P)  (P(pr 1 (tr l ))  P(pr 2 (tr l )))  P(tr u ) Switchable properties are preserved if the switch implementation satisfies a switch invariant tr u results from swapping tr l events with different origin messages sent by different protocols must be delivered in the same order Nuprl proof developed in parallel to implementation

Lessons learned Employing formal techniques at every design stage is of great use for building efficient network systems The LPE is capable of supporting “real” design - its theory is very expressive - reflection supports reasoning about program transformation Automation still needs to be increased More experience from applications is necessary The component-based approach is ideal for building adaptive systems

Extend scope of automation - Domain-specific reasoning strategies - Connect external inference engines - Formalize design knowledge (e.g. as theorems) - Techniques for automated system (code) synthesis Develop and deploy full reflection mechanism Build formal infrastructure for practitioners - Include library of formally documented mathematics  Plans Design & verification of new programs - New hybrid protocols (adaptivity) - Probabilistic protocols (scalability)