210 likes | 322 Vues
This project focuses on the development of an open Logical Programming Environment (LPE) that integrates programming languages and formal logic to enhance collaboration among formal systems. It aims to create reliable embedded systems through semantics-based transformations and optimizations. The advancements include new implementations, formal documentation mechanisms, and the capability to support adaptive networked systems. Key features such as local reflection, component-based optimizations, and fault tolerance are emphasized, ensuring high assurance in software components and architectures.
E N D
Advances in Logical Programming Environments Programming Logic Communications Secure software infrastructure Stuart Allen Mark Bickford Robert Constable Richard Eaton Christoph Kreitz Lori Lorigo
Project goals Build openLogical Programming Environment -integrate programming language and logic-share libraries of formalized mathematics-enable cooperation among formal systems-local reflection and code transformations Application to reliable embedded systems-semantics-based transformation and optimization-high-assurance software components and systems-formal component design
Progress • Nuprl LPE - new implementation with open architecture- formal documentation mechanisms- development of class theory- local reflection for weaving aspects • Application to networked systems -optimizationof protocol stacks- compositional protocol verification-formal design of adaptive systems
LPE Architecture • 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
Formal Documentation • Create documentation from formal objects- formal design expertise in “readable” form-screen display, LaTeX articles, HTML documents • 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
Class theory provides IOA formalisms IOA Ocaml(Ensemble) Java/JVM Ocaml Language Formalized in Nuprl External System Formalizes JVM Formal Class Theory • Extends Nuprl’s type theory • Provides expressive type constructs- Union, Intersection, Subtyping, Records, Modules • Supports formalization and composition of -Abstract specifications + concrete code of components-Modular verifications
Weaving and local reflection • Add properties to code Message Passing with Total Order Fault Tolerance Transform Total Order code to include rejoining & view-change code Fault Tolerant System with Total Order • Weaving asformal method requires local reflection-thms about semantical effect of syntactical transformations- reasoning about refinement + meta-properties
Formal Optimization • Optimize component-based network systems • generate fast-path for common case • compress message headers • Automate with Nuprl LPE (demo available) • Identify Common Case Predicates • Component code + CCP -> optimization theorem • System composition -> theorem composition • Composed theorem -> new system code Fast, abstract, verifiably correct results, speedup factor 3-4
Incremental through proof inheritance: • (A = P) (A B = P) • A B intersects: • states, actions • initial states, transitions Total = total ETO = total view Total Induction: 1. A I = I 2. B I = I 3. A.init B.init I A B = I ETO View View = view Compositional Protocol Verification
switch spec spec Formal Design of Adaptive Systems Joint work with Robbert Van Renesse, Xiaoming Liu, Ken Birman • Adapt system to suit run-time dynamics • - system upgrades • - changing conditions (higher security levels, …) • - use optimal implementations of components • Usually complicated • Building block approach • - generic switching protocol • constructshybrid protocolsfrom simpler ones • - flexible, easy to prove correct
Switching Protocol P1 P2 Switching Protocols: basic model • Normal mode • -forward messages to current protocol • - receive messages from current protocol • Switching Mode • -deliver messages from previous protocol • - buffer messages sent in the new protocol
meta- properties What kind of properties will be preserved by switching? Reliability? Prioritized Delivery? Integrity? Total Order? Confidentiality? Virtual Synchrony? In other words, what are the properties of these properties ? Inject formal methods at earliest design stage
switch spec spec spec network network Using the Nuprl LPE we proved that six meta-properties are sufficient for protocols to work correctly under a switching protocol
Formal Model of Communication • Communication property - predicate P on traces • Trace - List tr ofsend and receive events Send(p,m) : message p sent by process m Deliver(p,m) : message p received by process m
Reliability • p,m. Send(p, m) tr q. Deliver(q,m) tr • Integrity (T: set of trusted processes) • qT. Deliver(q,m) tr pT. Send(p,m) tr • Confidentiality • 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) Properties, formalized
Meta-property • Predicate M on properties of protocols • Expressed by relation R between traces tru,trl above and below a protocol layer M(P)tru,trl. P(trl) trlR tru P(tru) • Requires capability for higher order reasoning
Meta-properties for Switching } Safety Asynchrony Layered Communication Delayable Send-enabled } Memoryless Protocol Switching Composable Rdelay (tru ,trl) swap-adjacent(trl,tru) for e1,e2 with e1=Send(p,m1) e2 = Deliver(p,m2) Rasync (tru ,trl) swap-adjacent(trl,tru) for e1,e2 with process(e1) process(e2) Switchable(P)Msafety (P) … Mcomposable (P) Rcomposable (tru ,trl1,trl2) trl1trl2=[] interleave(tru,trl1,trl2) … Rsend-e (tru ,trl) tru= trl@ [Send(p1,m1),..,Send(pn,mn)] Rmemoryless (tru ,trl) tru= trl- [e | msg(e){m1,..,mn}] Rsafety (tru ,trl) trl tru
Verifying Hybrid Protocols Nuprlproof developed in parallel to implementation 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 Formal design at same pace as “informal” one
Lessons learned • The component-based approach is ideal for building adaptive systems • 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
Plans • Design & verification of new programs - New hybrid protocols (adaptivity)- Probabilistic protocols (scalability) • 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