1 / 22

David Evans cs.virginia/~evans

Lecture 13: Proof-Carrying Code. David Evans http://www.cs.virginia.edu/~evans. CS655: Programming Languages University of Virginia Computer Science. Menu. Challenge Question Solution (C++ overriding/overloading) Proof-Carrying Code My INFOSEC Malicious Code Talk.

rlauren
Download Presentation

David Evans cs.virginia/~evans

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. Lecture 13: Proof-Carrying Code David Evans http://www.cs.virginia.edu/~evans CS655: Programming Languages University of Virginia Computer Science

  2. Menu • Challenge Question Solution (C++ overriding/overloading) • Proof-Carrying Code • My INFOSEC Malicious Code Talk University of Virginia CS 655

  3. Subject: Re: C++: overriding problems! Date: Sat, 4 Mar 2000 20:19:34 -0500 (EST) From: Bjarne Stroustrup <bs@research.att.com> Reply-To: Bjarne Stroustrup <bs@research.att.com> To: avneesh@cs.virginia.edu > Delivered-To: bs@research.att.com > Date: Fri, 03 Mar 2000 18:09:53 -0500 > From: Avneesh Saxena <avneesh@cs.virginia.edu> > X-Accept-Language: en > MIME-Version: 1.0 > To: bs@research.att.com > Subject: C++: overriding problems! > Content-Transfer-Encoding: 7bit > > Sir, > I am Avneesh, a graduate student in the CS Dept, Univ of Virginia. I am currently taking a course on Programming languages in which we are doing a detailed study of subclassing mechanisms in computer languages. I have learned C++ from your book "The C++ Pgm'ing Language" which is written in a very clear and concise manner. Especially, the concepts are made clear and ambiguties about language features have been discussed and resolved in an appreciable manner. > However, I have run in a problem while trying to figure out what this code would do: [Unexpected results are noted as comments] University of Virginia CS 655

  4. > > #include<stdio.h> > > class A { > public: > void other() { printf("is an empty func in A\n"); }; > virtual void other(class A *a) { printf("In A\n"); } > }; //End class > > class B: public A { > public: > void other(class B *b) { printf("In B\n"); } > };//End class > > class C: public A { > public: > void other(class C *c) { printf("In C\n"); } > };//End class Your problem is that you think that the two other() function overloads. They don't: functions in different scope do not overload, so when you look at scope C::other(). If you want overloading you'll have to explicitly do so in C. One simple way of doing so is to say: using B::other; in C, but that's a relatively new feature. University of Virginia CS 655

  5. > void main(void) { > A a; B b; C c; > A *aPtr = &a; > B *bPtr = &b; > C *cPtr = &c; > > aPtr = bPtr; > aPtr->other(bPtr); //prints "in A", whereas we expect it to print > "In B" > //bPtr->other(); //Gives an error saying can't find the function > > }//End main > I have tried to run this code both through GCC v2.8.1 and MS-VC++, which give the same results. It appears that while we would accept other() to be accessible through the derived classes, the compiler doesn't find it. I think you mean "expect", but you expect wrongly. > The second (more serious)problem is when other(bPtr) is called, we expect it to execute the function which has been defined in class B as it overrides the function defines in class A as the type of the actual argument matches this more closely; however, it executes the base classes function (circumvents polymorphism!). I tried to check if this behavior was consistent with the language definition but I failed to find anything which would clarify things. So, I am left wondering whether this is a case of the compiler not understanding the language and doing something wrong or is it what the language desires? The compilers are wrong I suggest a re-read of the sections about deriving classes in your textbook. > I hope you will be able to clarify things for me, > Thanks, > Avs University of Virginia CS 655

  6. PCC: Basic Idea • Creating a proof is hard • Have to make up invariants, etc. • Checking a proof is easy • Simple mechanical application of rules • Guarantee properties of untrustworthy code by checking a proof provided by code producer University of Virginia CS 655

  7. Proof-Carrying Code Certifying Compiler Program Native Code Proof Code Producer Code Consumer Native Code Proof Ok Proof Checker Policy CPU University of Virginia CS 655

  8. Tamper with Code Certifying Compiler Program Native Code Proof Code Producer Wily Hacker Code Consumer Tampered Code Proof No! Proof Checker CPU University of Virginia CS 655

  9. Tamper with Both Certifying Compiler Program Native Code Proof Code Producer Wily P. Hacker Code Consumer Tampered Code Tampered Proof But it means the desired property still holds! Ok No! Proof Checker CPU University of Virginia CS 655

  10. What must the proof prove? Safety Policy • Depends on the policy • Code consumer must run VCGen (can’t trust proof unless it proves safety predicate) • VCGen can be developed from an operational semantics (like you did in PS2) VCGen Safety Predicate Program University of Virginia CS 655

  11. How many PCC systems in active use? • 2 • 100 • 1000 • 1 Million • 10 Million • > 20 Million • Java byte code verifier is • a limited implementation of PCC: • Bytecodes include extra • information on typing, • stack use, etc. • Bytecode verifier checks it to • enforce low-level code • safety properties • Peter Lee claims most linkers are • instances of PCC also. University of Virginia CS 655

  12. UmniVML2 Program::= TypeHint* Statement* TypeHint::= TYPE MemoryLocationType Type::= INTEGER | REF Type Statement::= STORE Expression_mExpression_v Expression_m must have typeref (typeof Expression_v). | READ Expression Expression must have type ref (integer). | WHILE Expression_l <= Expression_r Expression_l and Expression_r must have type integer. | ENDWHILE | HALT | CHECKTYPE ExpressionType Generates a run-time error if type of Expression is not Type. Expression::= ADD Expression_1Expression_2 Expression_1 and Expression_2 must have type integer. | ADDP Expression_1Expression_2 Expression_1 must have type ref(T). Expression_2 must have type integer. | DEREF Expression Expression must have type ref (T). University of Virginia CS 655

  13. An UmniVML2 Program [T0] TYPE M0 INT [T1] TYPE M1 REF INT [T2] TYPE M100-M200 INT % abbrev for 201 decls [0] STORE M0 0 [1] STORE M1 M100 [2] WHILE DEREF M0 <= 99 [3] CHECKTYPE DEREF M1 REF INT [4] READ DEREF M1 [5] STORE M1 ADDP DEREF M1 1 [6] STORE M0 ADD DEREF M0 1 [7] ENDWHILE [8] HALT University of Virginia CS 655

  14. VCGen for UmniVML2 VCGen (PC) = if Inst[PC] = STORE Expression_mExpression_v typeof (Expression_m) = ref (typeof (Expression_v)) & VCGenE (Expression_m) & VCGenE (Expression_v) & VCGen (PC + 1) if Inst[PC] = WHILE Expression_l <= Expression_r typeof (Expression_l) = integer & typeof (Expression_r) = integer & VCGenE (Expression_l) & VCGenE (Expression_r) & VCGen (PC + 1) & VCGen (<pc of next ENDWHILE>) if INST[PC] = READ Expression typeof (Expression) = ref (integer) & VCGenE (Expression) & VCGen (PC + 1) if INST[PC] = CHECKTYPE ExpressionType VCGen (PC + 1) can assume typeof (Expression) = Type if INST[PC] = ENDWHILE VCGen (PC + 1) if INST[PC] = HALT true University of Virginia CS 655

  15. VCGenE VCGenE (E) = if E = ADD Expression_1 Expression_2 typeof (Expression_1) = integer &typeof (Expression_2) = integer & VCGenE (Expression_1) & VCGenE (Expression_2) if E = ADDP Expression_1 Expression_2 typeof (Expression_1) = ref (T) &typeof (Expression_2) = integer & VCGenE (Expression_1) & VCGenE (Expression_2) if E = DEREF Expression typeof (Expression) = ref (T) & VCGenE (Expression) if E = IntLiteral true if E = MemoryLocation true University of Virginia CS 655

  16. VCGen for Program [T0] TYPE M0 INT [T1] TYPE M1 REF INT [T2] TYPE M100-M200 INT % abbrev for 201 decls [0] STORE M0 0 [1] STORE M1 M100 [2] WHILE DEREF M0 <= 99 [3] CHECKTYPE DEREF M1 REF INT [4] READ DEREF M1 [5] STORE M1 ADDP DEREF M1 1 [6] STORE M0 ADD DEREF M0 1 [7] ENDWHILE [8] HALT Project Group 1 Group 2 Group 3 Group 4 Group 5 Group 6 University of Virginia CS 655

  17. Constructing a Proof A = type environment = [ M0: ref (integer), M1: ref (ref (integer)), M100-M200: ref (integer)] Axioms are typing judgments (your PS2 solution) We need to show: A proves VCGen (0) Type bindings given by CHECKTYPE Expression Type are true until STORE Expression_x Expression or READ Expression_x where typeof (Expression_x) = Type. University of Virginia CS 655

  18. So Far • About as easy to generate these proofs as to check them, so no need to pass proof around with code. • Except: the type hints are really a proof! • CHECKTYPE is expensive – optimizing compiler should be able to remove it for this program University of Virginia CS 655

  19. An UmniVML2 Program [T0] TYPE M0 INT [T1] TYPE M1 REF INT [T2] TYPE M100-M199 INT % abbrev for 200 decls [0] STORE M0 0 [1] STORE M1 M100 [2] WHILE DEREF M0 <= 99 [3] READ DEREF M1 [4] STORE M1 ADDP M1 1 [5] STORE M0 ADD M0 1 [6] ENDWHILE [7] HALT Need a loop invariant University of Virginia CS 655

  20. Requirements for Invariant • Strong enough to prove: Inv & Pred  VCGen ([3] READ DEREF M1) Inv & (DEREF M0 <= 99)  typeof (DEREF M1) = ref (integer) • Weak enough to prove: TypeHints + [0] STORE M0 0 + [1] STORE M1 M100  Inv • Weak and strong enough to prove WHILE loop axioms Inv & (DEREF M0 <= 99) { [3] READ DEREF M1 [4] STORE M1 ADDP M1 1 [5] STORE M0 ADD M0 1 } Inv University of Virginia CS 655

  21. Loop Invariant Inv = DEREF (DEREF M1) = 100 + DEREF M0 & DEREF M0 >= 0 This is the “proof” attached to the code. Once you have it, checking is easy! University of Virginia CS 655

  22. PCC Summary • Code producer provides a checkable proof of desired property • Code consumer verifies the proof • Can use invariants, type hints, etc. but must not assume they are true • Help direct the checker to construct a proof quickly • Enables optimizations not possible without proof • Enables guarantees not possible without proof (lack of run-time errors) University of Virginia CS 655

More Related