1 / 42

January 22, 2001

Types, Proofs, and Safe Mobile Code The unusual effectiveness of logic in programming language research Peter Lee Carnegie Mellon University. January 22, 2001. NSF/CISE Workshop on The Unusual Effectiveness of Logic in Computer Science. Logic in PL research. Type-directed compiling.

taran
Télécharger la présentation

January 22, 2001

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. Types, Proofs, andSafe Mobile CodeThe unusual effectiveness of logic in programming language researchPeter LeeCarnegie Mellon University January 22, 2001 NSF/CISE Workshop on The Unusual Effectiveness of Logic in Computer Science

  2. Logic in PL research Type-directed compiling Logic programming Abstract Interpretation -calculus Formal verification Category theory Domain theory Term rewriting systems Logic frameworks Operational semantics Type theory Denotational semantics Proof-carrying code Logic is the foundation of modern PL research.

  3. This talk • A somewhat personal account, by necessity a rather narrow slice. • But similar stories can be found in almost all areas of PL research.

  4. Logic as Language

  5. Logic and languages • To PL researchers, logics and languages are often interchangeable. • A vivid example of this is in formal proofs. • Consider: • Write “x is a proof of P” as x:P.

  6. Formal proofs • We can write formal proofs by application of inference rules. • An example: • If we have a proof x of P and a proof y of Q, then x and y together constitute a proof of P  Q. • Or, more compactly: • Given x:P, y:Q then (x,y):P*Q.

  7. Formal proofs • Another familiar example: • Assume we have a proof x of P. If we can then obtain a proof b of Q, then we have a proof of P  Q. • Given [x:P] b:Q then fn (x:P) => b : P  Q. • More: • Given x:P*Q then fst(x):P • Given y:P*Q then snd(y):Q

  8. Proofs and types • So, for example: • fn (x:P*Q) => (snd(x), fst(x)) : P*Q  Q*P • We can develop full metalanguages based on this principle of proofs as programs, propositions as types. • Typechecking gives us proofchecking! • Codified in languages such as ML.

  9. Applications • This isomorphism has had many applications in logic and in CS. • Proof development systems. • NuPrl, Coq, LCF, … • Advanced programming languages. • Prolog. • Logical framework languages. • Edinburgh Logical Framework.

  10. Logical frameworks • The Edinburgh Logical Framework (LF) is a particularly useful language for specifying logics.

  11. LF example Fragment of first-order logic, Pfenning’s Elf syntax. exp : type pred : type pf : pred -> type true : pred /\ : pred -> pred -> pred => : pred -> pred -> pred all : (exp -> pred) -> pred truei : pf true andi : {P:pred} {R:pred} pf P -> pf R -> pf (/\ P R) andel : {P:pred} {R:pred} pf (/\ P R) -> pf P impi : {P:pred} {R:pred} (pf P -> pf R) -> pf (=> P R) alli : {P:exp -> pred} ({X:exp} pf (P X)) -> pf (all P) alle : {P:exp -> pred} {E:exp} pf (all P) -> pf (P E)

  12. LF example • The representation of PPP for some predicate P: • The proof of this predicate has the following Elf representation: (=> P (/\ PP)) (impi P (/\ PP) ([X:pf P] andi PP x x))

  13. Language as Logic

  14. Languages and logic • To PL researchers, languages and logics are often interchangeable. • A vivid example of this is in type theory.

  15. Type theory • A standard application of type theory involves the following: • Operational (run-time) semantics is defined by an inference system. • Type system is also defined by an inference system. • Logic is used to prove the soundness of the type system wrt the semantics. • A programming language is a logic.

  16. Soundness • Soundness: • Well-typed programs are guaranteed to stay within the boundaries defined by the operational semantics. • Well-typed programs won’t go wrong.

  17. Practical benefits • Soundness can be hard to prove. • But it essentially converts the very difficult negative property (program won’t go wrong) into a positive property (program is well-typed). • Only need to prove soundness once.

  18. Applications • Current research often involves defining the logical core of a language and then studying its properties. • Existing languages. • ML, Haskell, JVML, … • New design and implementation features. • Type-directed compiling, region inference, linear typing, …

  19. Proofs, Types, and Safe Mobile Code

  20. The code safety problem Please install and execute this. Full cartoon

  21. Is this safe to execute? CPU Code Safety Code Trusted Host

  22. Theorem Prover Flexible and powerful. CPU Formal verification Code But really really really hard and must be correct. Trusted Host

  23. CPU A Key Idea: Explicit Proofs Code Certifying Prover Proof Checker Proof Trusted Host

  24. Typically native or VM code Formal proof safety in LF Proof-Carrying Code[Necula & Lee, OSDI’96] A rlrrllrrllrlrlrllrlrrllrrll… B

  25. Reasonable in size (0-10%). No longer need to trust this component. Simple, small (<52KB), and fast. CPU Proof-Carrying Code Code Certifying Prover Proof Checker Proof

  26. The Role of Languages and Logic • Civilized programming languages can provide “safety for free”. • Well-formed/well-typed  safe. • Idea: Arrange for the compiler to “explain” why the target code it generates preserves the safety properties of the source program.

  27. Object code Source code Proof Looks and smells like a compiler. CPU % spjc foo.java bar.class baz.c -ljdk1.2.2 Automation viaCertifying Compilation Certifying Prover Certifying Compiler Proof Checker

  28. Safety Policies in LF Fragment of rules for the Java type system. jfloat : exp. jinstof : exp -> exp. of : exp -> exp -> pred. faddf : {E:exp} {E':exp} pf (of E jfloat) -> pf (of E' jfloat) -> pf (of (fadd E E') jfloat). ext : {E:exp} {C:exp} {D:exp} pf (jextends C D) -> pf (of E (jinstof C)) -> pf (of E (jinstof D)).

  29. Program checking A proof for (saferd4 (add src_1 (add (imul edx_1 4) 8))) in the Java specification looks like this (excerpt): (rdArray4 A0 A2 (sub0chk A3) szint (aidxi 4 (below1 A7))) This proof can be easily validated via LF type checking.

  30. Themes and Conclusions

  31. Coherence Main Entry: co·her·encePronunciation: kO-'hir-&n(t)s, -'her-Function: nounDate: 15801: the quality or state of cohering: as a: systematic or logical connection or consistency b: integration of diverse elements, relationships, or values2: the property of being coherent • Research in programming languages is largely directed towards achieving coherence in software systems.

  32. Coherence • Coherence requires: • ability to analyze/verify components, and • communicate descriptions of components. • Logic is canonical, in the sense of being the only foundation for this.

  33. Esthetics vs. pragmatics • Many of the methods and results are motivated as much by esthetic as they are by pragmatic concerns. • Practical engineering consequences: • Minimality and clarity of expression. • Scaling up by study of “core” logics. • Can sometimes be divorced from real-world problems, but hard to predict.

  34. Practicality • In recent years, a trend towards picking the low-hanging fruit. • Eliminate “simple errors”. • Exposed by the Web, plug-ins, embedded systems, etc. • Even machine languages! • Small theorems about big programs.

  35. Conclusions • For much of the history of CS, PL research meant design of languages and compiler technology. • Today, PL technology and concepts advance logic and are applied directly to software artifacts. • “LF in the Unix kernel.”

  36. A logical approach OK, but let me quickly look over the instructions first. Please install and execute this. Code producer Host

  37. A logical approach Code producer Host

  38. A logical approach This store instruction is dangerous! Code producer Host

  39. A logical approach Can you prove that it is always safe? Code producer Host

  40. A logical approach Yes! Here’s the proof I got from my certifying Java compiler! Can you prove that it is always safe?  Code producer Host

  41. A logical approach Your proof checks out. I believe you because I believe in logic.  Code producer Host return

More Related