Extensible Code Verification

1. Compiled Program Test Cases Compiler Test Case SPIM  COOL Compiler next states E Stressed CS164 Student Compiler Test Case Coolaid COOL Verifier SPIM COOL Compiler Relaxed CS164 Student PCC OV Less Flexible More Flexible FPCC OV Less Scalable More Scalable PCC OV More Trusted Code Less Trusted Code Extensible Code Verification Kun Gao (Senior EECS) with Professor George Necula, Evan Chang, Robert Schneck, Adam Chlipala Overview Motivation Solution When we download programs from the Internet, how do we know the program is safe to run? This is a fundamental question asked in the area of Program Verification. Program Verification has rich backgrounds in theoretical work as well as practical application. Every year, papers are published on new discoveries and tools to verify more kinds of programs. • An individual receives code from an untrusted source • Before executing the code, he wants to verify certain properties about the code, such as memory safety • The individual does not want to restrict the producer of the code to: • Particular programming language • Particular coding convention The Open Verifier is a trusted architecture for verifying code. By embedding an untrusted verifier into the Open Verifier, the Open Verifier can now reason effectively about the code. This untrusted verifier is called the Extension. • The code producer supplies the verifier along with the code • flexibility: code producer can provide a verifier with specialized reasoning about the code • scalability: specialized reasoning for the enforcement mechanism encoded in executable form • amount of trusted code: verifier extension with specialized reasoning is not trusted, does not add to code that must be correct safe? code When given code, how do we know it is safe to run? Then how do we verify the code without restriction? Question: code ? Too hard to prove correctness of the verifier Embed the untrusted verifier as an extension in a trusted infrastructure (the Open Verifier) untrusted trusted The safest thing we can do is say “no” to every program, but that wouldn’t be very useful! Traditional approaches such as Proof Carrying Code (PCC) has either been fixed towards a particular compiler for scalability, while Foundational PCC (FPCC) has sacrifices ease of generating proofs for flexibility. The goal is to say “Yes” to every safe program and “No” to every unsafe program. OpenVer code Obviously, the person who wrote the code knows a lot more about the safety properties of the code. We can have the person writing the code send a verifier also. But this means we need to check that the verifier is correct. This would be too difficult. verifier  extension verifier extension untrusted trusted code verifier Say ‘Yes’ to every safe program, and ‘No’ to every unsafe program verifier Too hard to prove correctness of the verifier code At each step in the verification, we first check with the verifier extension. To make sure it is giving us the right answer, the trusted parts ask the extension questions phrased in logic. Goal: untrusted trusted Architecture Application Summary The Open Verifier Architecture consists of the Decoder and Director, which are trusted, and the Extension, which is untrusted. To test the architecture, the COOL programming language was selected. COOL is significant because it implements many modern object oriented features and has well documented language specifications. Extensible Code Verification allows code producers to write untrusted verifier extensions. These extensions when used with the open verifier architecture, allows the code producer flexibility in use various safety enforcement mechanisms to simplify proof generation by incorporating specialized reasoning. The result is a system that is smaller and more flexible than traditional PCC, and more scalable than Foundational PCC. Decoder Director state s trusted untrusted Extension code Open Verifier is more flexible than traditional PCC and more scalable than FPCC • instruction at state ssafe if P holds • proceed to next states D • a proof ofP • proceed to next states E and a proof that EcoversD COOL Open Verifier used to debug COOL compilers We implemented this system using OCaml. Currently, the architecture supports parsing of MIPS, x86, with extensions for Coolaid and TAL. Keeping the trusted open verifier small means we can more easily check it is correct. Currently, the trusted components are the architecture, is only around 3000 lines of code. A graphical tool in the style of debugger allows users to step through code and setup breakpoints. Interesting ideas can be tested on the Open Verifier architecture, such as new COOL language features including exceptions. Future work includes incorporating radically different language features and implementations to test the robustness and flexibility of the architecture. COOL stands for Classroom Object Oriented Language, a simplified compiler used in introductory compiler courses. There are more COOL compilers than COOL programs! Debugging compilers is tedious and difficult. The Cool Open Verifier was used to test our ideas for an open verification architecture for proof-carrying code. It provides students with a helpful compiler debugging tool If you are interested in the Extensible Code Verification, and would like to contribute, please email Prof. Necula: necula@cs.berkeley.edu