Top Banner
Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University Lecture 1 (of 3) June 21-22, 2003 University of Oregon 2004 Summer School on Software Security
78

Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Dec 31, 2015

Download

Documents

Jerome Marshall

Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University. Lecture 1 (of 3) June 21-22, 2003 University of Oregon. 2004 Summer School on Software Security. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Lectures onProof-Carrying Code

Peter LeeCarnegie Mellon University

Lecture 1 (of 3)June 21-22, 2003

University of Oregon

2004 Summer School on Software Security

Page 3: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University
Page 4: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

“After a crew member mistakenly entered a zero into the data field of an application, the computer system proceeded to divide another quantity by that zero. The operation caused a buffer overflow, in which data leaked from a temporary storage space in memory, and the error eventually brought down the ship's propulsion system. The result: the USS Yorktown was dead in the water for more than two hours.”

Page 5: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

According to CERT, buffer overflow attacks are the #1 exploit for network security attacks.

http://www.cert.org/summaries/

Page 6: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

buffer overflow!

+ =

Page 7: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University
Page 8: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University
Page 9: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Automotive analogy

“If the automobile had followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and ...

Page 10: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Automotive analogy

“If the automobile had followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year killing everyone inside."

- Robert Cringely

Page 11: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Cars in the Real World

Problems at Mercedes: Forced to buy back 2000 copies of the latest

E-Class sedan, due to problems with computing and telecommunications systems

J.D.Power initial quality rankings have dropped to 15th (even below Chevrolet!) in 2003

board member Jurgen Hubbert says this is directly related to the effort to be a “technology leader”

Page 13: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Observations

Many failures are due to simple problems “in the details”

Code reuse is necessary but perilous

Updateable/mobile code is essential

Performance matters a lot

Page 14: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Opportunities

Progress depends fundamentally on our ability to reason about programs.

The opportunities are great.

Who will provide the technology for systems that work?

Page 15: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

About these lectures

The main topic is proof-carrying code, an example of certified code

It won’t be possible to go through all aspects in complete detail

But I hope to provide background to make it easier to get started with research

Page 16: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

The Code Safety Problem

Page 17: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

The Code Safety Problem

Please install and execute this.

Page 18: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

“Applets, Not Craplets”- Luca Cardelli, 1996

Page 19: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

“If you have ‘process’ without ‘inspiration,’ all you end up with is well-documented crap.”

— Dr. John C. Sommerer, CTO, Johns Hopkins

Advanced Physics Lab

Page 20: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Code Safety

CPU

Code

Trusted Host

Is this safe to execute?

Page 21: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Approach 1Trust the code producer

CPU

Code

Trusted Host

sig

Trusted 3rd Party

PK1

PK1

PK2

PK2

Trust is based on personal authority, not program properties

Scaling problems?

Page 22: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Approach 2Baby-sit the program

CPU

Code

Trusted Host

Execution monitor

Expensive

E.g., Software Fault Isolation [Wahbe & Lucco], Inline Reference Monitors [Schneider]

Page 23: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Approach 3Java

CPU

Code

Trusted Host

Interp/ JIT

Expensive and/or big

Limited in expressive power

Verifier

Page 24: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

TheoremProver

Approach 4Formal verification

CPU

Code

Flexible andpowerful.

Trusted Host

But really reallyreally hard andmust be correct.

Page 25: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

A key idea: Checkable certificates

CertifyingProver

CPU

ProofChecker

Code

Proof

Trusted Host

Page 26: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

A key idea: Checkable certificates

CertifyingProver

CPU

Code

ProofProof

Checker

Page 27: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Proof-Carrying Code[Necula & Lee, OSDI’96]

A

B

Page 28: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Five Frequently Asked Questions

Page 29: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Question 1

How are the proofs represented and checked?

Page 30: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Formal proofs

Write “x is a proof of predicate P” as x:P.

What do proofs look like?

Page 31: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Example inference rule

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, in ASCII:

Given x:P, y:Q then (x,y):P*Q.

Page 32: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

More inference rules

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 rules:

Given x:P*Q then fst(x):P Given y:P*Q then snd(y):Q

Page 33: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Types and proofs

So, for example:

fn (x:P*Q) => (snd(x), fst(x)) : P*Q Q*P

This is an ML program!

Also, typechecking provides a “smart” blackboard!

Page 34: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Curry-Howard Isomorphism

In a logical framework language, predicates can be represented as types and proofs as programs (i.e., expression terms).

Furthermore, under certain conditions typechecking is sufficient to ensure the validity of the proofs.

Page 35: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

“Proofs as Programs”

“Propositions as Types”

Page 36: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

LF

The Edinburgh Logical Framework language, or LF, provides an expressive language for proofs-as-programs.

Furthermore, its use of dependent types allows, among other things, the axioms and rules of inference to be specified as well

Page 37: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Oracle strings

A

B rlrrllrrllrlrlrllrlrrllrrll…

Page 38: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Question 2

How well does this work in practice?

Page 39: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

The Necula-Lee experiments

CertifyingProver

CPU

Code

Proof

Simple,small (<52KB),and fast.

No longer need totrust this component.

ProofChecker

Reasonable in size (0-10%).

Page 40: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Crypto test suite results

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

PCC Java JIT

sec

Page 41: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Question 3

Aren’t the properties we’re trying to prove undecideable?

How on earth can we hope to generate the proofs?

Page 42: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

How to generate the proofs?

Proving theorems about real programs is indeed hard

Most useful safety properties of low-level programs are undecidable

Theorem-proving systems are unfamiliar to programmers and hard to use even for experts

Page 43: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

The role ofprogramming languages

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

Page 44: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Certifying Compilers[Necula & Lee, PLDI’98]

Intuition:

Compiler “knows” why each translation step is semantics-preserving

So, have it generate a proof that safety is preserved

This is the planned topic for tomorrow’s lecture

Page 45: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Certifying compilation

CertifyingCompiler

CPULooks and smells like a compiler.

% spjc foo.java bar.class baz.c -ljdk1.2.2

Sourcecode

Proof

Objectcode

CertifyingProver

ProofChecker

Page 46: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Java

Java is a worthwhile subject of research.

However, it contains many outrageous and mostly inexcusable design errors.

As researchers, we should not forget that we have already done much better, and must continue to do better in the future.

Page 47: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Question 4

Just what, exactly, are we proving?

What are the limits?

And isn’t static checking inherently less powerful than dynamic checking?

Page 48: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Semantics

Define the states of the target machine

S = (, , pc)

and a transition function Step(S).

Define also the safe machine states via the safety policy SP(S).

program

register state

program counter

Page 49: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Semantics, cont’d

Then we have the following predicate for safe execution:

Safe(S) = n:Nat. SP(Stepn(S))

and proof-carrying code:

PCC = (S0:State, P:Safe(S0))

Page 50: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Reference Interpreters

A reference interpreter (RI) is a standard interpreter extended with instrumentation to check the safety of each instruction before it is executed, and abort execution if anything unsafe is about to happen.

In other words, an RI is capable only of safe execution.

Page 51: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Reference Interpreterscont’d

The reference interpreter is never actually implemented.

The point will be to prove that execution of the code on the RI never aborts, and thus execution on the real hardware will be identical to execution on the RI.

Page 52: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Question for you

Suppose that we require the code to execute no more than N instructions.

Is such a safety property enforceable by an RI?

Page 53: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Question for you

Suppose we require the code to terminate eventually. Is such a safety property enforceable by an RI?

Page 54: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

What can’t be enforced?

Informally:

Safety properties Yes “No bad thing will happen”

Liveness properties Not yet “A good thing will eventually happen”

Page 55: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Static vs dynamic checking

PCC provides a basis for static enforcement of safety conditions

However, PCC is not just for static checking

PCC can be used, for example, to verify that necessary dynamic checks are carried out properly

Page 56: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Question 5

Even if the proof is valid, how do we know that it is a safety proof of the given program?

Page 57: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Please install and execute this.

OK, but let me quickly look over the instructions first.

Code producer Host

Page 58: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Code producer Host

Page 59: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

This store instruction is dangerous!

Code producer Host

Page 60: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Can you prove that it is always safe?

Code producer Host

Page 61: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Can you prove that it is always safe?

Yes! Here’s the proof I got from my certifying Java compiler!

Code producer Host

Page 62: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Your proof checks out. I believe you because I believe in logic.

Code producer Host

Page 63: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

The safety policy

We need a method for

identifying the dangerous instructions, and

generating logical predicates whose validity implies that the instruction is safe to execute

In practice, we will also need specifications (pre/post-conditions) for

each required entry point in the code, as well as the trusted API.

Page 64: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

High-level architecture

Explanation

CodeCode

analyzer

Checker

Safetypolicy

Agent

Host

Page 65: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

High-level architecture

Proof

CodeVerificationconditiongenerator

Proof

checker

Proofrules

Agent

Host

Page 66: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

VCgen

The job of identifying dangerous instructions and generating predicates for them is performed via an old method:

verification-condition generation

Page 67: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

A Case Study

Page 68: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

A case study

As a case study, let us consider the problem of verifying that programs do not use more than a specified amount of some resource.

s ::= skip | i := e | if e then s else s | while e do s | s ; s | use e

e ::= n | i | read() | e + e | e – e | …

Denotes the use of n pieces of the resource, where e evaluates to n

Page 69: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Case study, cont’d

Under normal circumstances, one would implement the statement:

use e;

in such a way that every time it is executed, a run-time check is performed in order to determine whether n pieces of the resource are available (assuming e evaluates to n).

Page 70: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Case study, cont’d

However, this stinks because many times we should be able to infer that there are definitely available resources.

…if … then use 4; else use 5;use 4;…

If somehow we know that there are 9 available here…

…then certainly there is no need to check any of these uses!

Page 71: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

An easy (well, probably) case

Program Static i := 0 while i < 10000 use 1 i := i + 1

We ought to be able to prove statically whether the uses are safe

Page 72: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

A hopeless case

Program Dynamic while read() != 0 use 1

Page 73: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

An interesting case

Program Interesting N := read() i := 0 while i < N use 1 i := i + 1

In principle, with just a single dynamic check, static proof ought to be possible

Page 74: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Also interesting

Program AlsoInteresting while read() != 0 i := 0 while i < 100 use 1 i := i + 1

Page 75: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

A core principle of PCC

In the code,

the implementation of a safety-critical operation

should be separated from

the implementation of its safety checks

Page 76: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Separating use from check

So, what we would like to do is to separate the safety check from the use.

We do this by introducing a new construct, acquire

acquire requests n amount of resource; use no longer does any checking

s ::= skip | i := e | if e then s else s | while e do s | s ; s | use e | acquire e

Page 77: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

Separation permits optimization

The point of acquire is to allow the programmer (or compiler) to hoist and coalesce the checks

…acquire 9;if … then use 4; else use 5;use 4;…

…acquire n;i := 0;while (i++ < n) do { … use 1; …}

It will be up to PCC to verify that each use is definitely safe to execute

Page 78: Lectures on Proof-Carrying Code Peter Lee Carnegie Mellon University

High-level architecture

Proof

CodeVerificationconditiongenerator

Proof

checker

Proofrules

Agent

Host