Stuart Allen Mark Bickford Robert Constable

Richard Eaton Christoph Kreitz Lori Lorigo

Secure software infrastructure

Logic

Programming

Communications

Advances in Advances in Logical Programming Logical Programming

EnvironmentsEnvironments

Build open Logical Programming

Environment

- 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

• Application to networked systems - optimization of protocol stacks - compositional protocol verification -- formal designformal design of adaptive of adaptive

systemssystems

• 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 LPE ArchitectureArchitecture

• 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 Formal DocumentationDocumentation

• 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 Formal Class TheoryTheory

• Extends Nuprl’s type theory

• Add properties to code Message Message Passing Passing

with with Total OrderTotal Order

Fault Fault TolerantTolerant

System with System with Total OrderTotal Order

Transform Total Order code to include rejoining &

view-change code

Fault Fault ToleranceTolerance

• Weaving as formal method requires local reflection - thms about semantical effect of syntactical transformations

- reasoning about refinement + meta-properties

Weaving and local Weaving and local reflectionreflection

• Optimize component-based network systems

Formal Formal OptimizationOptimization

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, transitionsInduction:

1. A I = I2. B I = I3. A.init B.init

I A B = I

View = view

View

ETO

ETO = total view

Total = total

Total

Compositional Protocol Compositional Protocol Verification Verification

• Adapt system to suit run-time dynamics - system upgrades

- changing conditions (higher security levels, …)

- use optimal implementations of components

• Usually complicatedswitch

spec spec• Building block approach - generic switching protocol

constructs hybrid protocols from simpler ones

- flexible, easy to prove correct

Formal Design of Adaptive SystemsJoint work with Robbert Van Renesse, Xiaoming Liu, Ken Birman

• Normal mode - forward messages to current protocol

- receive messages from current protocol

Switching Protocol

P1 P2

• Switching Mode - deliver messages from previous protocol

- buffer messages sent in the new protocol

Switching Protocols: basic Switching Protocols: basic modelmodel

What kind of properties What kind of properties will be preserved by will be preserved by switching? switching?

In other words, what are the properties of these properties ?

Reliability?

Total Order?Integrity?Confidentiality?

Prioritized Delivery?

Virtual Synchrony?

propertiespropertiesmeta-meta-

Inject formal methods at earliest design Inject formal methods at earliest design stagestage

we proved that six meta-properties are sufficient for protocols to work correctly under a switching protocol

switch

specspec

spec

networknetwork

Using Using the Nuprlthe Nuprl LPELPE

Formal Model of Formal Model of CommunicationCommunication

• 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 qT. Deliver(q,m) tr pT. Send(p,m) tr )

• Reliability p,m. Send(p, m) tr q. Deliver(q,m) tr

Properties, formalizedProperties, formalized

• Integrity (T: set of trusted processes)

qT. Deliver(q,m) tr pT. Send(p,m) tr

• Total order q1,q2,m1,m2. Deliver(q1,m1) tr Deliver(q2,m1) tr Deliver(q1,m2) tr Deliver(q2,m2) tr Deliver(q1,m1) < Deliver(q1, m2)

Deliver(q2,m1) < Deliver(q2, m2)

• Expressed by relation R between traces tru,trl above and below a protocol layer

M(P) tru,trl. P(trl) trl R tru P(tru)

Meta-propertyMeta-property

• Predicate M on properties of protocols

• Requires capability for higher order reasoning

Meta-properties for Meta-properties for SwitchingSwitching

}}

Layered Communication

Protocol Switching

Rsend-e (tru ,trl) tru = trl @ [Send(p1,m1),..,Send(pn,mn)]

Rasync (tru ,trl) swap-adjacent(trl ,tru) for e1,e2

with process(e1) process(e2)

Rdelay (tru ,trl) swap-adjacent(trl ,tru) for e1,e2

with

e1=Send(p,m1) e2 =

Deliver(p,m2)

Rsafety (tru ,trl) trl truRcomposable (tru ,trl1,trl2 ) trl1trl2=[] interleave(tru,trl1,trl2) …

Rmemoryless (tru ,trl) tru = trl - [e | msg(e){m1,..,mn}]

Switchable(P) Msafety (P) … Mcomposable

(P)

AsynchronySafety

DelayableSend-enabled

Composable

Memoryless

Formal design at same pace as Formal design at same pace as “informal” one“informal” one

Verifying Hybrid Verifying Hybrid ProtocolsProtocols

P.tru,trl. switch_invariant(tru,trl)

Switchable(P)

(P(pr1(trl)) P(pr2(trl))) P(tru)Switchable properties are preserved if the switch implementation satisfies a switch invariant• tru results from swapping trl 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)