1 / 21

Advances in Logical Programming Environments

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.

stella-finch
Download Presentation

Advances in Logical Programming Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Advances in Logical Programming Environments Programming Logic Communications Secure software infrastructure Stuart Allen Mark Bickford Robert Constable Richard Eaton Christoph Kreitz Lori Lorigo

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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 

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. Reliability • p,m. Send(p, m)  tr  q. Deliver(q,m)  tr • Integrity (T: set of trusted processes) • qT. Deliver(q,m)  tr  pT. Send(p,m)  tr • Confidentiality • qT. Deliver(q,m)  tr  pT. 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

  16. 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

  17. 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) trl1trl2=[]  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

  18. 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

  19. 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

  20. 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 

More Related