The Problem

1
The Problem

• Fluid software cannot be trusted to behave as
  advertised
• unknown origin (must be assumed to be malicious)
• known origin (can be erroneous or even malicious)
• We must worry about
• extrinsic code properties (non-semantic
  properties)
• e.g., author, time of creation, 3rd
  party-endorsements, ...
• semantic code properties (behavioral properties)
• e.g., memory safety, lack of information flow,
  etc.
• To handle untrusted fluid software we need
• safety enforcement technologies, and
• design and development methodologies

2
The State of the Art

• Cryptographic techniques
• require external trust relationships
• good for non-semantic properties
• Security monitors
• monitor the execution and halt if a fault is
  detected
• impose data representation constraints
• run-time checking alone is limited
• hard to detect certain faults
• halting the execution not always acceptable
• Static checking
• reduced run-time cost
• quickly becomes undecidable for optimized code
• JVM type safety for unoptimized intermediate code

3
Simple And Powerful Static Checking

• The code is accompanied by a detailed proof
• Proof-Carrying Code (PCC)

Proof Checker
Yes/No

• The proof explains the code to the static
  checker
• No more proving, just proof checking
• The hard work is delegated to the code source
• where it should be
• The proof certifies that the hard work was done
  properly

4
Features of PCC

• Safety without sacrificing performance
• works for low-level languages (even machine code)
• works for optimized code
• The trusted code base is small
• checking is easier than proving
• no need to use (and trust) a compiler
• Flexible and general (in principle)
• need a specification that captures the property
  of interest
• and a proof of that property for the untrusted
  code
• if you can prove it, PCC can check it!
• install one checker for a multitude of policies
• But what about generating the proofs?

5
Certifying Compilation

• We typically expect our tools to establish
  certain basic properties
• e.g., type safety for a compiler for a type-safe
  language
• e.g., lack of race conditions for an Esterel
  compiler
• We must either
• run the tool ourselves (we better trust it)
• trust the user to run it (hard to enforce)
• Alternatively, use tools that certify their
  output
• delegate but do not trust
• effective way to debug the tools themselves !

Certifying Code Generator
Proof Checker
Yes/No
6
Current Status

• Proof-carrying code
• Intel x86 and DEC Alpha implementations ( 50Kb
  code)
• Proofs are 10-75 the size of the code (for type
  safety)
• Fast proof checking ( 100Kb/s) parameterized by
  the specification of the safety policy
• Certifying compiler
• for a subset of C
• combines performance (on par with GCC -O4)
• with type safety
• for full Java (under development)
• Near future
• certification back-end for GCJ (GNU Compiler for
  Java)
• gain leverage from using off-the-shelf untrusted
  compilers

7
What next?

• Even in C we try to write type safe programs
• Is it possible to discover why a C program is
  safe?
• ratify a broad set of safe programming
  practices
• there will be failures
• hopefully they point to programming errors
• or else, the tool suggests convenient stylistic
  adjustments
• or else, the tool inserts run-time checks
• this could be compiler independent

Heuristic-based certifier
Untrusted code
Proof Checker
Yes/No
8
Criteria for Success

• 1 year
• A toolkit for producing provably-safe native
  methods with off-the-shelf Java compilers
• 3 years
• A toolkit for certifying type safety of C
  programs
• Common thinking in years
• Type and memory faults are as common as uncaught
  memory parity errors
• If an application crashes, replace the
  motherboard