Download presentation
Presentation is loading. Please wait.
Published byAudrey Munoz Modified over 11 years ago
1
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
2
Research objective (of the FLINT group) To build a certified software platform with real guarantee of reliability & security ! Hardware certified L1 software legacy SW layer1 legacy SW layer2 legacy SW layer3 legacy SW layer4 certified L2 SW certified L3 SW certified L4 SW certified L5 SW
3
The lowest SW layer is the key! A buggy L1 software can take over the machine easily! Hardware buggy L1 software (or VM) legacy SW layer1 legacy SW layer2 legacy SW layer3 legacy SW layer4 certified L2 SW certified L3 SW certified L4 SW certified L5 SW infected L2 SW infected L3 SW infected L4 SW infected L5 SW
4
Must be Trusted! Structure of our certified framework certified code (proof + machine code) machine model safety policy mechanized meta-logic proof checker Proof Checker Yes CPU Safety Policy Proof machine code No
5
What makes a good mechanized meta logic? Youd 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
6
How to scale? Modularity, modularity, modularity! specification S 1 binary code C 1 formal proof P 1 specification S 2 binary code C 2 formal proof P 2 specification S 3 binary code C 3 formal proof P 3 specification S 4 binary code C 4 formal proof P 4 specification S 6 binary code C 6 formal proof P 6 specification S 5 binary code C 5 formal proof P 5 specification S binary code C formal proof P Linking
7
Another form of modularity Software is often organized as a vertical stack of abstractions! Not everything is certified at the assembly level! Hardware certified L1 software certified L2 SW certified L3 SW certified L4 SW certified L5 SW Must accurately specify & certify all these interfaces!
8
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
9
Related research projects at Yale Certifying different language & OS abstractions: –certified assembly programming [CAP ESOP02] –embedded code pointers [XCAP POPL06] –non-preemptive threads [CCAP ICFP04 & CMAP ICFP05] –stack-based control abstractions [SCAP PLDI06] –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 ESOP02] –garbage collector & mutator [McCreight et al on-going]
10
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
11
TAL vs. CAP Type-based Approach –TAL [Morrisett98] –Touchstone PCC [Colby00] –Syntactic FPCC [Hamid02] –FTAL [Crary03] –LTAL [Chen03] –… –Modular –Generate proof easily –Type safety Logic-based Approach –Original PCC [Necula98] –CAP [Yu03] –CCAP/CMAP [Yu04, Feng05] –XCAP [Ni & Shao 06] –SCAP [Feng et al 06] –… –Expressive –Advanced properties –Good interoperability
12
This talk! We also show how to embed TAL into our new XCAP! SCAP [Feng et al PLDI06]XCAP [Ni & Shao POPL06] Can we have the best of both worlds? Can a Hoare-style CAP system support: –embedded code pointers? –closures? –exceptions? –runtime stacks? –general references w. weak update? –recursive data structures?
13
Syntax of target machine TM
14
Operational semantics of TM
15
Mechanized meta logic All implemented in the Coq proof assistant!
16
XCAP assertion language
17
Validity rules for PropX [P] = ¢ ` P
18
Soundness of interpretation
19
XCAP inference rules: top level
20
XCAP inference rules: instructions
21
Soundness of XCAP
22
Memory mutation in XCAP? Strong update! –special conjunction (p * q) in separation logic –directly definable in Prop and PropX –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
23
XCAP extension: general reference
24
XCAP ext.: supporting weak update
25
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)
26
XCAP ext.: recursive predicates
27
TAL: type definitions
28
TAL typing rules: top level
29
TAL typing rules: instructions
30
TAL typing rules: instructions (contd)
31
TAL uses syntactic subtyping!
32
Well-formed state in TAL
33
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
34
TAL-to-XCAP: translating value types
35
translation of preconditions translation of code heap types translation of data heap types TAL-to-XCAP: other translations
36
TAL-to-XCAP: typing preservation
37
Conclusion user application library TAL device driver OS kernel firmware XCAP XCAP can be extended to support general reference, weak update, and recursive specification ! We give a direct embedding of TAL into XCAP.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.