1 / 22

Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads

Explore challenges in verifying safety & correctness of OS kernels/hypervisors with concurrency, interrupts, & concurrency with interrupts. Learn about a Hoare-style program logic for modular verification of low-level programs, with a focus on memory partitioning and separation logic.

sandraandrews
Download Presentation

Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads Xinyu Feng Toyota Technological Institute at Chicago Joint work with Zhong Shao (Yale), Yuan Dong (Tsinghua Univ.) and Yu Guo (USTC)

  2. Many challenges: Low-level C/Assembly code Code loading Concurrency Interrupts Device drivers & I/O … How to verify safety & correctness of OS kernels / Hypervisors? Is verification possible? How to do it in a clean & modular way?

  3. B: concurrent code with explicit interrupts How to verify ??? Layering of Simplified Kernel Code

  4. irq0 irq1 Concurrency with Interrupts: Challenges (1) (4) (3) (2) (5) Asymmetric preemption between handlers and non-handler code Intertwining between threads and handlers Asymmetric synchronization: cli/sti are different from locks

  5. Our Contributions A Hoare-style program logic for modular verification of low-level programs with interrupts and concurrency.

  6. AIM – I : Single Threaded-Code with Interrupts (data heap) H f1: I1 pc addu … cli sti iret … j f 0 1 2 … f2: I2 r1 r2 r3 … rn ih: ISR (register file) R ie … (code heap) C (state) S ::=(H,R,ie) ::={fI}* (program) P ::=(C,S,pc)

  7. Example: Teeter-Totter right left 50 50 while(true){ cli; if([right] == 0){ sti; break; } [right] := [right]-1; [left] := [left]+1; sti; } print(“left wins!”); timer: if([left] == 0){ print(“right wins!”); iret; } [left] := [left]-1; [right] := [right]+1; iret; How to guarantee non-interference?

  8. Non-Interference? Program invariant: There is always a partition of memory among concurrent entities, and each concurrent entity only access its own part. But note: The partition is dynamic: ownership of memory can be dynamically transferred. cli/sti can be modeled as operations that trigger memory ownership transfer.

  9. - { Ph } AIM – I : The Memory Model INV B A Memory Non-handler Handler - { Ph } INV sti … iret cli … The memory partition is logical, not physical!

  10. emp empty heap l  n l n pq p q p  q pq Separation Logic to Enforce Partition [Ithtiaq & O’Hearn’01, Reynolds’02]

  11. INV cli B B sti B A B B INV INV AIM – I : cli/sti INV B A B ie = 1 ie = 0

  12. sti cli Example: Teeter-Totter right INV: m, n. (left  m)  (right  n)  (m+n = 100) left 50 50 while(true){ -{emp  ie=1} cli; -{emp * INV} ... [right] := [right]-1; [left] := [left]+1; -{INV} sti; -{emp  ie=1} } timer: -{INV} if([left] == 0){ print(“right wins!”); -{INV} iret; } [left] := [left]-1; [right] := [right]+1; -{INV} iret;

  13. … (data heap) H R R R f1: pc pc pc (ready. queue) Q f2: … 2 1 0 w1 ih: r1 r2 r3 … rn w2 (register file) R ie … cli/sti switch block w unblock w pc wn B AIM-II : Multi-threaded code with interrupts (code heap) C (state) S ::=(H,R,ie) (program) P ::=(C,S,B,Q,pc)

  14. … (data heap) H R R R f1: pc pc pc (ready. queue) Q f2: … 2 1 0 ih: r1 r2 r3 … rn (register file) R ie pc cli/sti switch block w unblock w Non-interference? w1 w2 (code heap) C (state) S ::=(H,R,ie) … wn B Use memory partition to control interference!

  15. T1 T2 C A INV1 INV AIM – II : Memory Model INV B A

  16. T1 T1 T2 T2 T1: cli T1: C' T1: C T1: A T1: A' T1: sti INV1 INV1 INV INV T1 T2 C' A' INV1 INV AIM – II : cli/sti T1 T2 C A INV1 INV ie = 1 ie = 0

  17. T1 T1 T2 T2 untouched T1: switch T2: C T2: C' T2: A T2: A' switch INV1 * INV preserved INV1 INV1 INV INV T1 T2 T2: switch T1: C' T1: A' INV1 INV AIM – II : switch T1 T2 T1: C T1: A INV1 INV …sti…cli… ie = 0

  18. T1 ! T2 block T2: C T2: A INV1 INV unblock block T1 ! T2 T1 T2 switch T1: C' T1 : A' T2 : C' T2 : A' INV1 INV INV1 INV AIM-II: block/unblock T1 T2 ? T2 T1: C T1: A INV1 INV ! ! Thread 1 Thread 2

  19. R1 R2 Rn AIM-II : block/unblock Threads block themselves to wait for resources. locks: wait for resources protected by locks condition variables: wait for conditions to come true R can be empty w1 Unifies different semantics of Condition Variables: Mesa style Hoare style Brinch-Hansen style Read our paper for details! w2 … wn B

  20. Sep. Logic Utilities (e.g. Queues) Implementations – An Infrastructure for x86 verification 26,000 12,000 Locks, Condition variables Timer handler, yield/sleep switch, block, unblock AIM Logic & Soundness SCAP 26,000 3,000 6,300 4,000 x86 semantics (a subset) 3,300 Coq (Higher-Order Logic with Inductive Def.) Around 82,000 lines of Coq code See http://flint.cs.yale.edu/publications/aim.html

  21. Summary • Abstract Machine & Program Logic • Hardware interrupts + preemptive threads • Ownership transfer semantics • cli, sti, switch, block, unblock • Implementations • Infrastructure for x86 code verification • Certified x86 modules • Future work • Multi-processor platforms • Liveness properties • Verification of C programs

  22. Thank you!

More Related