263155eadbad4c704cabc2ce9282c561.ppt
- Количество слайдов: 37
A Translation from Typed Assembly Language to Certified Assembly Programming Zhong Shao Yale University Joint work with Zhaozhong Ni Paper URL: http: //flint. cs. yale. edu/flint/publications/talcap. html August 11, 2006
Research objective (of the FLINT group) To build a certified software platform with real guarantee of reliability & security ! certified L 5 L 4 L 3 L 2 SW SW legacy SW SW certified L 1 software Hardware layer 4 layer 3 layer 2 layer 1
The lowest SW layer is the key! A buggy L 1 software can take over the machine easily! certified L 5 SW infected certified L 4 SW infected certified L 3 SW infected certified L 2 SW legacy SW SW layer 4 layer 3 layer 2 layer 1 buggy L 1 software (or VM) Hardware
Structure of our certified framework Safety Policy Proof machine code Proof Checker No Yes CPU • certified code (proof + machine code) • • machine model safety policy mechanized meta-logic proof checker Must be Trusted!
What makes a good mechanized meta logic? You’d better be very paranoid! • The logic must be “rock-solid”, i. e. , consistent! • The logic must be expressive to express everything a hacker wants to say • Support explicit, machine-checkable proof objects • The logic must be simple so that the proof checker can be hand-verified • Can serve as logical framework and meta-logical framework to allow one to prove using specialized logics • Compatible with “automated proof construction”
How to scale? Modularity, modularity! specification S 1 binary code C 1 formal proof P 1 specification S 3 binary code C 3 formal proof P 3 specification S 5 binary code C 5 formal proof P 5 specification S 2 binary code C 2 formal proof P 2 specification S 4 binary code C 4 formal proof P 4 specification S 6 binary code C 6 formal proof P 6 Linking specification S binary code C formal proof P
Another form of modularity Software is often organized as a vertical stack of abstractions! Not everything is certified at the assembly level! certified L 5 SW certified L 4 SW certified L 3 SW certified L 2 SW certified L 1 software Hardware Must accurately specify & certify all these interfaces!
A really “juicy” research area … Many interesting & exciting problems: • How to certify each standard language and OS abstraction? – – – general code pointers procedure call/return general stack-based control abstraction mutable data structures (& malloc/free …) self-modifying code (& OS boot loader …) interrupt/signal handling device drivers and IO managers thread libraries and synchronization multiprocessor and memory model OS kernel/user abstraction ………… • How to combine proof assistant with general-purpose programming? • Other exciting interplays btw machine-checked proofs & computation
Related research projects at Yale Certifying different language & OS abstractions: – – – certified assembly programming [CAP ESOP’ 02] embedded code pointers [XCAP POPL’ 06] non-preemptive threads [CCAP ICFP’ 04 & CMAP ICFP’ 05] stack-based control abstractions [SCAP PLDI’ 06] self-modifying code & local reasoning [Cai et al GCAP on-going] thread libraries and synchronizations [Ni et al on-going] interrupts & multiprocessors [Ferreira et al on-going] open framework for interoperability [Feng et al OCAP on-going] boot-loaders & preemptive threads [Feng et al on-going] memory management using malloc/free [CAP ESOP’ 02] garbage collector & mutator [Mc. Creight et al on-going]
Features of a CAP-style system • All built on a mechanized meta logic (e. g. , Coq) • Both the machine-level program and the property are specified by formulas in the meta logic • Like TLA except our meta logic is mechanized • Hoare-style assertions & inference rules enforce both the correctness & type safety properties • No need of a separate type system; not a “refinement” • Assertion languages can vary: • Borrow those from Coq (shallow embedding) --- CAP • Hybrid: Coq assertions + a thin layer of syntax --- XCAP
TAL vs. CAP • Type-based Approach • Logic-based Approach – – – TAL [Morrisett 98] Touchstone PCC [Colby 00] Syntactic FPCC [Hamid 02] FTAL [Crary 03] LTAL [Chen 03] … – Modular – Generate proof easily – Type safety – – – Original PCC [Necula 98] CAP [Yu 03] CCAP/CMAP [Yu 04, Feng 05] XCAP [Ni & Shao 06] SCAP [Feng et al 06] … – Expressive – Advanced properties – Good interoperability
Can we have the best of both worlds? • Can a Hoare-style CAP system support: – embedded code pointers? XCAP [Ni & Shao POPL’ 06] – closures? – exceptions? SCAP [Feng et al PLDI’ 06] – runtime stacks? – general references w. weak update? – recursive data structures? This talk! We also show to embed TAL into our new XCAP!
Syntax of target machine TM
Operational semantics of TM
Mechanized meta logic All implemented in the Coq proof assistant!
XCAP assertion language
Validity rules for Prop. X [P] = ¢ ` P
Soundness of interpretation
XCAP inference rules: top level
XCAP inference rules: instructions
Soundness of XCAP
Memory mutation in XCAP? • Strong update! – special conjunction (p * q) in separation logic – directly definable in Prop and Prop. X – explicit alias control, popular in system level • Weak update (general reference)? – mutable reference (int ref) in ML – managed data pointers (int __gc*) in. NET – rely on GC to recycle memory
XCAP extension: general reference
XCAP ext. : supporting weak update
Recursive specification in XCAP? • Simple recursive data structures! – linked list, queue, stack, tree, etc. – supported via inductive definition of Prop • Complex recursive structures with ECP? – object (self refers to the entire object) – threading invariant (each thread assumes others)
XCAP ext. : recursive predicates
TAL: type definitions
TAL typing rules: top level
TAL typing rules: instructions
TAL typing rules: instructions (cont’d)
TAL uses “syntactic” subtyping!
Well-formed state in TAL
TAL-to-XCAP translation Step #1: we build a “logic-based” TAL that uses semantic subtyping Step #2: translating regular TAL into “logic-based” TAL (this is fairly straight-forward!) Step #3: translating “logic-based” TAL into XCAP
TAL-to-XCAP: translating value types
TAL-to-XCAP: other translations • translation of preconditions • translation of code heap types • translation of data heap types
TAL-to-XCAP: typing preservation
Conclusion XCAP can be extended to support general reference, weak update, and recursive specification ! We give a direct embedding of TAL into XCAP. TAL user application library device driver XCAP OS kernel firmware
263155eadbad4c704cabc2ce9282c561.ppt