Extensible Code Verification Kun Gao (Senior EECS) with Professor George Necula, Evan Chang, Robert Schneck, Adam Chlipala 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 code ? untrustedtrusted Then how do we verify the code without restriction? Overview 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. code When given code, how do we know it is safe to run? 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. Decoder instruction at state s safe if P holds proceed to next states D Director Extension code trusted untrusted state s a proof of P proceed to next states E and a proof that E covers D next states E SPIM COOL Compiler SPIM Compiler Test Case Compiled Program Test Cases Stressed CS164 Student COOL Compiler Coolaid COOL Verifier Compiler Test Case Relaxed CS164 Student 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 Too hard to prove correctness of the verifier Embed the untrusted verifier as an extension in a trusted infrastructure (the Open Verifier) untrustedtrusted verifier extension OpenVer code verifier extension More FlexibleLess Flexible OVPCC More ScalableLess Scalable OVFPCC Less Trusted CodeMore Trusted Code OVPCC code safe? untrustedtrusted verifier Too hard to prove correctness of the verifier MotivationSolution code Question: Goal: Say ‘Yes’ to every safe program, and ‘No’ to every unsafe program 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. ArchitectureApplicationSummary The Open Verifier Architecture consists of the Decoder and Director, which are trusted, and the Extension, which is untrusted. 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. 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. 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. 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. COOL Open Verifier used to debug COOL compilers 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. Open Verifier is more flexible than traditional PCC and more scalable than FPCC If you are interested in the Extensible Code Verification, and would like to contribute, please Prof. Necula: 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 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.