a kripke logical relation between ml and assembly

18
A Kripke Logical Relation Between ML and Assembly Chung-Kil Hur and Derek Dreyer MPI-SWS POPL 2011

Upload: imelda

Post on 25-Feb-2016

24 views

Category:

Documents


0 download

DESCRIPTION

A Kripke Logical Relation Between ML and Assembly. Chung- Kil Hur and Derek Dreyer MPI-SWS POPL 2011. Compiler Correctness by Simulation Relation. execution. compiler. Read. Read. Write. Write. Send. Send. Limitation of Simulation Relation: Lack of Compositionality. compiler 1. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: A  Kripke  Logical  Relation Between  ML and Assembly

A Kripke Logical Relation Between ML and Assembly

Chung-Kil Hur and Derek DreyerMPI-SWS

POPL 2011

Page 2: A  Kripke  Logical  Relation Between  ML and Assembly

execution

≈compilerRead Read

WriteWrite

Send Send

Compiler Correctness by Simulation Relation

Page 3: A  Kripke  Logical  Relation Between  ML and Assembly

≈compiler1

≈compiler2

≈?

≈?

Limitation of Simulation Relation: Lack of Compositionality

Page 4: A  Kripke  Logical  Relation Between  ML and Assembly

When is a high-level program “equivalent” to a low-level program?

≈Want a notion of “program equivalence” that is1. preserved under linking2. as large as possible

Essential Question

Page 5: A  Kripke  Logical  Relation Between  ML and Assembly

• Canonical notion of program equivalence for high-level programs:

C[] and C[] return the same observable results for

every program context C

What is Contextual Equivalence?

Page 6: A  Kripke  Logical  Relation Between  ML and Assembly

• Compositionality:

• Extensionality:

What is good about Contextual Equivalence?

Page 7: A  Kripke  Logical  Relation Between  ML and Assembly

But:• Does not work for low-level languages– Contexts have too much distinguishing power

• Does not work for relating different languages– Can’t use same context for two different languages

What is wrong with Contextual Equivalence?

Page 8: A  Kripke  Logical  Relation Between  ML and Assembly

• Typically used as technique for proving contextual equivalence in a higher-order language

• Take logical relation as “definition of program equivalence”

between high-level and low-level languages

𝑓 2 (𝑔2 ) :T

𝑓 2

𝑔2

Logical Relations to the Rescue! [Benton & Hur, ICFP’09]

Page 9: A  Kripke  Logical  Relation Between  ML and Assembly

𝑓 2 (𝑔2 ) :Tapply(

𝑓 2

𝑔2

𝑓 2

𝑔2 𝑓 2 (𝑔2 ) :T

• Compositionality and extensionality are built in!

• Unlike , logical relations can be adapted to relate different languages.– ICFP’09 paper related pure -calculus and SECD

Why is Logical Relation a good definition?

Page 10: A  Kripke  Logical  Relation Between  ML and Assembly

• Scale ideas to ML-like high-level language and assembly-like low-level language– Builds on recent work on step-indexed Kripke

logical relations (by Dreyer et al. POPL’09, ICFP’10)

• Handle interaction with a garbage collector– Distinguish between logical and physical memories

(idea from McCreight et al. PLDI’07, ICFP’10)

Contributions of This Work

Page 11: A  Kripke  Logical  Relation Between  ML and Assembly

• Relating ML to assembly is challenging– Need a way to “tame” state, at both high and low levels

• Kripke logical relations arelogical relations indexed by “possible worlds”– Worlds encode invariants about state

• Dreyer et al. [ICFP’10] generalize worlds to express state transition systems– Supports reasoning about how state evolves over time

Kripke Logical Relations

Page 12: A  Kripke  Logical  Relation Between  ML and Assembly

Irreversible State Change [Dreyer et al.]

e1= λf :𝐮𝐧𝐢𝐭→𝐮𝐧𝐢𝐭 .(f ();1)

λf :𝐮𝐧𝐢𝐭→𝐮𝐧𝐢𝐭 . (x≔1 ; f (); ! x )e2=𝐥𝐞𝐭 x=𝐫𝐞𝐟 0 𝐢𝐧

𝑥↪0

(can be in either state)(no successor)

Page 13: A  Kripke  Logical  Relation Between  ML and Assembly

Self-Modifying Code

bg move wk4 bg+3 move wk5 1 jmp alloc move [wk5+0]h bg+5 jmp wk0

move wk3 bg+10 isr wk4 wk3 minus wk4 wk4 666 isw wk3 wk4 plus wk3 wk3 1 (jneq bg+6 wk3 bg+21)+666 (isw bg+5 (jmp bg+12) )+666

bg+12 (move [wk1+0]h bg+13 )+666bg+13 (plus sp sp 1 )+666

(move [sp-1]s wk0 )+666 (move wk1 wk2 )+666 (move wk0 bg+18 )+666 (jmp [wk1+0]h )+666 (move wk5 1 )+666 (minus sp sp 1 )+666

(jmp [sp-0]s )+666

01100110010101001110110001101011 01101010101101110101000100100101

bg+12 10110101001111010101010111000100bg+13 01010110101001010101110110001010

11011001010111000101010101001010 11010101000101011010010101010101 01110110100101011100101010100101 10101010100100110110001000111010 10010001000011101111001111001010 01110100010010101010010101010010

01100010001000111100111100111011

jneq bg+6 wk3 bg+21 isw bg+5 (jmp bg+12)

bg+12 move [wk1+0]h bg+13bg+13 plus sp sp 1

move [sp-1]s wk0 move wk1 wk2 move wk0 bg+18 jmp [wk1+0]h move wk5 1 minus sp sp 1

jmp [sp-0]s

jmp bg+12bg+5 ℓ1

ℓ2

bg+5ℓ3

bg+5bg+13

bg+5bg+13

e1= λf :𝐮𝐧𝐢𝐭→𝐮𝐧𝐢𝐭 .(f ();1)

Page 14: A  Kripke  Logical  Relation Between  ML and Assembly

(CASE 2)(CASE 1)(CASE 3)

Reasoning about Self-Modifying Code

bg move wk4 bg+3 move wk5 1 jmp alloc move [wk5+0]h bg+5 jmp wk0

move wk3 bg+10 isr wk4 wk3 minus wk4 wk4 666 isw wk3 wk4 plus wk3 wk3 1 01100110010101001110110001101011 01101010101101110101000100100101

bg+12 10110101001111010101010111000100bg+13 01010110101001010101110110001010

11011001010111000101010101001010 11010101000101011010010101010101 01110110100101011100101010100101 10101010100100110110001000111010 10010001000011101111001111001010 01110100010010101010010101010010

01100010001000111100111100111011

jneq bg+6 wk3 bg+21 isw bg+5 (jmp bg+12)

bg+12 move [wk1+0]h bg+13bg+13 plus sp sp 1

move [sp-1]s wk0 move wk1 wk2 move wk0 bg+18 jmp [wk1+0]h move wk5 1 minus sp sp 1

jmp [sp-0]s

jmp bg+12bg+5

encrypted decrypted

ℓ bg+5bg+13

ℓ↪ bg+5 ℓ↪ bg+13

e1= λf :𝐮𝐧𝐢𝐭→𝐮𝐧𝐢𝐭 .(f ();1)

decryptedℓ↪ bg+5

encryptedℓ↪ bg+5

decrypted3

encrypted3

Page 15: A  Kripke  Logical  Relation Between  ML and Assembly

• Public vs. private transitions– Idea from Dreyer et al., useful for modeling “well-bracketed” state change,

e.g. assumptions about stack & callee-save registers

• Logical vs. physical memories– Idea from McCreight et al., critical for defining logical relations that enjoy

monotonicity property in the presence of GC

• Symmetric, “language-generic” presentation of logical relation

• Compiler correctness for simple compiler– Full proofs in online appendix

What Else is in the Paper?

Page 16: A  Kripke  Logical  Relation Between  ML and Assembly

• Progress toward a more general notion of equivalence between high- and low-level programs

• We’ve generalized previous work to a much more realistic setting

• Applying cool new ideas from recent work on both logical relations and certified compilers

Conclusion

Page 17: A  Kripke  Logical  Relation Between  ML and Assembly

• Compositional Compiler Correctness for C(Linking for CompCert)– Realistic Compilation– Multiphase Compilation

Future Work

Page 18: A  Kripke  Logical  Relation Between  ML and Assembly

• Linking between different languages

≈ML

≈C

≈ML+C

Future Work