Scalable Certification for Scalable Certification for Typed Assembly Language Typed Assembly Language Dan Grossman (with Greg Morrisett) Cornell University 2000 ACM SIGPLAN Workshop on Types in Compilation AFTER AF
Types After After Compilation Compilation -- -- Why? Why? Types Verifying object code is “well-behaved” means we needn’t trust the code producer • Producer-supplied types guide verification • Encourages compiler robustness • Promises efficient untrusted plug-ins To maximize benefit, we want... September 2000 2 TIC00 Montreal
Certified Code Design Goals Certified Code Design Goals • Low-level target language avoids performance / trusted computed base trade-off • Source-language & compiler independent avoids hacks, promotes re-use, the object-code way • Permit efficient object code otherwise, just interpret or monitor at run time • Small Certificates and Fast Verification otherwise, only small programs are possible Still learning how to balance these needs in practice September 2000 3 TIC00 Montreal
State of the Art State of the Art Low-level Compiler- Efficient Efficient independent Code Certification JVML No No Yes? Yes PCC Yes No Yes Yes ECC Yes No No Yes Appel/ Yes! Yes Yes? ??? Felty TAL Yes Yes Yes (This talk) September 2000 4 TIC00 Montreal
Scalable Certification in 15 mins Scalable Certification in 15 mins • Classification of Approaches • Why Compiler Independence Makes Scalability Harder • Techniques that Make TAL Work • Experimental Results • Summary of some lessons learned See the paper for much, much more September 2000 5 TIC00 Montreal
Approach #1 -- -- Bake It In Bake It In Approach #1 If you allow only one way, no annotations needed and it’s trivial to check Examples: • Grouping code into procedures • Function prologues • Installing exception handlers The type system is at a different level of abstraction An analogy: RISC vs. CISC September 2000 6 TIC00 Montreal
Approach #2 -- -- Don’t Optimize Don’t Optimize Approach #2 Optimizations that are expensive to prove safe are expensive to certify Examples: • Dynamic type tests • Arithmetic (division by zero, array-bounds elimination) • Memory initialized before use Better code can make a system look worse A new factor for where to optimize? September 2000 7 TIC00 Montreal
Approach #3 -- -- Reconstruct Reconstruct Approach #3 Don’t write down what the verifier can easily determine Examples: • Don’t put types on every instruction/operand • Omit proof steps where inversion suffices • Re-verify target code at each “call” site (virtual inlining) Can trade time for space or get a win/win Analogy: source-level type inference w/o the human factor September 2000 8 TIC00 Montreal
Approach #4 -- -- Compress Compress Approach #4 Let gzip and domain-specific tricks solve our problems • For annotation size, no reason not to compress • Easy to pipeline decompression, but certification is not I/O bound Then again, object code compresses too September 2000 9 TIC00 Montreal
Approach #5 -- -- Abbreviate Abbreviate Approach #5 Give the code producer type-level tools for parameterization and re-use • Just (terminating) functions at the type level • Usually easy for the code producer • Improves certificate size, but may hurt certification time Not much harder than implementing the lambda-calculus September 2000 10 TIC00 Montreal
Approaches Summary Approaches Summary • Bake it in • Don’t optimize • Reconstruct • Compress • Abbreviate Now let’s get our hands dirty... September 2000 11 TIC00 Montreal
An Example – – Code Pre Code Pre- -condition condition An Example int foo(int x) { return x; } foo: τ MOV EAX, [ESP+0] RETN Pre-condition describes calling convention: where are the arguments, results, return address, exception handler (what’s an exception anyway), ... September 2000 12 TIC00 Montreal
Bake it in... Bake it in... int foo(int x) { return x; } foo: int → int MOV EAX, [ESP+0] RETN Pre-condition describes calling convention: where are the arguments, results, return address, exception handler (what’s an exception anyway), ... September 2000 13 TIC00 Montreal
Really bake it in... Really bake it in... int foo(int x) { return x; } foo_Fii: MOV EAX, [ESP+0] RETN Pre-condition describes calling convention: where are the arguments, results, return address, exception handler (what’s an exception anyway), ... September 2000 14 TIC00 Montreal
Or spell it all out... Or spell it all out... int foo(int x) { return x; } foo: ∀ a:T,b:T,c:T,r1:S,r2:S,e1:C,e2:C. {ESP: {ESP:int::r1@{EAX:exn,ESP:r2,M:e2}::r2 EAX:int, EBX:a,ESI:b,EDI:c, M:e1+e2, EBP: {EAX:exn,ESP:r2,M:e2}::r2, }::int::r1@{EAX:exn,ESP:r2,M:e2}::r2, EBP: {EAX:exn,ESP:r2,M:e2}::r2, EBX:a, ESI:b, EDI:c, M:e1+e2} MOV EAX, [ESP+0] RETN Pre-condition describes calling convention: arguments, results, return address pre-condition, callee-save registers, exception handler, ... September 2000 15 TIC00 Montreal
What to do? What to do? F = λ args λ results . ∀ a:T,b:T,c:T,r1:S,r2:S,e1:C,e2:C. args {ESP: {ESP:int:: r1@{EAX:exn,ESP:r2,M:e2}::r2 result EAX:int, EBX:a,ESI:b,EDI:c, M:e1+e2, EBP: {EAX:exn,ESP:r2,M:e2}::r2, args }::int:: r1@{EAX:exn,ESP:r2,M:e2}::r2, EBP: {EAX:exn,ESP:r2,M:e2}::r2, EBX:a, ESI:b, EDI:c, M:e1+e2} • Compress (compiler invariants are very repetitious) • Don’t optimize (fewer invariants) • Abbreviate: foo: F [int] int September 2000 16 TIC00 Montreal
And Reconstruction Too And Reconstruction Too If we elide a pre-condition, the verifier can re-verify the block for each predecessor • Restrict to forward jumps to prevent loops • Beware exponential blowup • Bad news: Optimal type placement appears intractable • Good news: Naive heuristics save significant space September 2000 17 TIC00 Montreal
A real application A real application A bootstrapping compiler from Popcorn to TAL • Popcorn: • “Java w/o objects, w/ polymorphism and limited pattern-matching” • “ML w/o closures or modules, w/ C-like core syntax” • “Safe C – pointerful, garbage collection, exceptions” • Compiler: • Conventional • Graph-coloring register allocation, null-check elimination • Verifier: OCaml 2.04 • System: Pentium II, 266MHz, 64MB, NT4.0 September 2000 18 TIC00 Montreal
Bottom line – – it works it works Bottom line • Source code: 18KLOC, 39 files • Target code: 816 Kb (335 Kb after strip ) • Target types: 419 Kb • Compilation: 40 secs • Assembly: 20 secs • Verification: 34.5 secs And proportional to file size September 2000 19 TIC00 Montreal
The engineering matters The engineering matters (Recall: 419Kb of types, 34.5 secs to verify) • Without abbreviations: 2041Kb • Without pre-condition elision: 550Kb • Without either: 4500Kb • As much elision as legal: 402Kb, 740 secs • gzip reduces the 419Kb to 163Kb September 2000 20 TIC00 Montreal
Also studied... Also studied... • Differences among code styles • Techniques for speeding up the verifier • Other forms of reconstruction • Being “ gzip -friendly” September 2000 21 TIC00 Montreal
Some engineering lessons Some engineering lessons • Compiler-independence produces large repetitious annotations. • Abbreviations are easy and space- effective, but not time-effective. • Overhead should never be proportional to the number of loop-free paths in the code. • Certification bottlenecks often do not appear in small, simple programs. September 2000 22 TIC00 Montreal
Recommend
More recommend
