formally verifying exceptions in low level code with
play

Formally verifying exceptions in low-level code with Separation - PowerPoint PPT Presentation

Formally verifying exceptions in low-level code with Separation Logic Marco Paviotti and Jesper Bengtson IT University of Copenhagen 22nd October Nordic Workshop on Programming Theory (NWPT) Reykjavik, Iceland 1 Verification of low-level


  1. Formally verifying exceptions in low-level code with Separation Logic Marco Paviotti and Jesper Bengtson IT University of Copenhagen 22nd October Nordic Workshop on Programming Theory (NWPT) Reykjavik, Iceland 1

  2. Verification of low-level code • Hand-crafted code often found in security-critical places (e.g. kernels) • Mechanically verifying low-level, unstructured code is crucial • Categorical models have successfully inspired separation logic higher-order and shared memory concurrency (iCAP, Svendsen and Birkedal) • for verification of low-level code (Jensen, Kennedy and Benton) • • Kernels make heavy use of exceptions/interrupts • There is no nice logic/model accounting for these behaviours

  3. Interrupts IDT table When an interrupt fires the CPU: • looks up the address of the Save handler in the IDT table • Stores the return address on the top of the stack Restore • Jumps to the handler IRET It is the handler responsibility to IDT Register restore the state and return from the interrupt Typical Handler Structure 3

  4. Motivating Example Unmapped mov ESI , info ; mov EDI , [ESI]; mov [EDI] , 0; Store add EDI , 4; EDI mov [ESI] , EDI . 0 EDI= [ESI] 4

  5. Motivating Example Unmapped 0 mov ESI , info ; 0 mov EDI , [ESI]; 0 !! mov [EDI] , 0; 0 Store EDI= [ESI] add EDI , 4; 0 0 mov [ESI] , EDI . 0 0 5

  6. Our contributions We rely on an existing Coq formalisation of the assembly x86[1,2] • Semantics and instruction rules for exceptions • We prove their use by verifying the memory allocator example 1 Andrew Kennedy, Nick Benton, Jonas Braband Jensen, and Pierre-Evariste Dagand. Coq: the world’s best macro assembler? In PPDP 2013. 2J. B. Jensen, N. Benton, and A. J. Kennedy. High-level separation logic for low-level code. POPL 2013 6

  7. Goals and Related work • First step towards asynchronous interrupts and thus Verification of Device Drivers and Schedulers (Concurrency) • Our end is similar to Feng et al.’s[1], but • here we don’t rely on abstractions • Want: a nice model 1 X. Feng, Z. Shao,Y. Guo, Y. Dong. Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads 7

  8. Coq and assembly • Code is data • Unstructured assembly code • Memory : list 32 bool * list 32 bool • Using notation can write assembly code in Coq

  9. Higher-Order Separation Logic for low-level code[1] Post-Condition Precondition ` (safe ⌦ EIP 7! j ? Q ) ! (safe ⌦ EIP 7! i ? P ) ↵ i..j 7! c Code Meaning Q “If the code is safe to run from { P } c { Q } N × ( Σ → Prop) → Prop when ‘c’ is a code block then it is safe to run from the state ” P 1J. B. Jensen, N. Benton, and A. J. Kennedy. High-level separation logic for low-level code. POPL 2013 9

  10. Loop example It is safe to sit in a tight loop forever: ` (safe ⌦ EIP 7! i ) ↵ i 7! JMP i Proof. It suffices to show that if the loop is safe for k-1 steps (“later”) then it is safe for k steps (“now”) safe ⌦ EIP 7! i ↵ i 7! JMP i safe ⌦ EIP 7! i ↵ i 7! JMP i ` . safe ⌦ EIP 7! i ↵ i 7! JMP i ` Löb Induction . S ` S The “later” modality is due to [Nakano, 2000] ` S 10

  11. Rule format r1 ptr v1 { } safe ⌦ (EIP 7! i ? ) r2 v2 i..j 7! mov[ r 1 ] , r 2 { } r1 ptr v2 safe ⌦ (EIP 7! j ? ) r2 v2 11

  12. Exceptions: mov as jumps { } ) safe ⌦ (EIP 7! i ? ESP ptr ? i..j 7! mov[ r 1 ] , r 2 { } . ) ESP safe ⌦ (EIP 7! fail ? ptr j Unmapped location Invariant r2 v2 • The IDT is present in the memory, • The record to the GPE links to the fail address r1 !! ptr 12

  13. Memory allocator P mov ESI , info ; safe ⌦ EIP 7! i ? EDI 7! mov EDI , [ESI]; ? ESP 7! s ? s � 4 ..s 7! sv mov [EDI] , 0; add EDI , 4; mov [ESI] , EDI . Q1 Q2 safe ⌦ EIP 7! j ? INTL 7! 0 safe ⌦ EIP 7! fail ? INTL 7! 1 ? ESP 7! s ? s � 4 ..s 7! sv ? ESP 7! s � 4 ? 9 ret.s � 4 ..s 7! ret ? 9 p. EDI 7! p + 4 9 unk.p.. ( p + 4) 7! unk Invariant IDT Unmapped ESI? ? ? Store GP Exception fail

  14. Correctness of the Allocator Exception occurs Precondition Theorem ` ((safe ⌦ Q 1 ^ safe ⌦ Q 2 ) ! safe ⌦ P ) ↵ i..j 7! c ⌦ R IDT Success Coq code 14

  15. Conclusions • We extended Jensen et al.’s formalisation to cover programs with exceptions • The logic is robust: we didn’t need a new model/logic • I didn’t have time for showing: a lot of Coq code What do we do next? • Are interrupts effects or threads? • Concurrency as a primitive (CSL/Shared memory) Ti anks!

Recommend


More recommend