An Automata-Theoretic Approach to Hardware/Software Co-verification

1. An Automata-Theoretic Approach to Hardware/Software Co-verification Thomas Ball Microsoft Research Joint work with Juncao Li and Fei Xie Dept. of Computer Science, Portland State University Vladimir Levin and Con McGarvey Microsoft Corporation

5. Hardware/Software (HW/SW) Interfaces are Pervasive… • Windows XP • Over 35,000 drivers (over 100,000 versions) for different devices (Murphy and Garzia, 2004) • Linux • 70% of code for drivers that operate hardware (Chou, et al., 2001)

6. And Unreliable… • In Windows • Drivers cause 85% reported failures • (Swift, 2005) • At least 52.6% of Windows crashes involve HW/SW interaction • (Sinha, 2005) • In Linux • Seven times more driver failures • (Chou, et al., 2001) • Lots of failures cannot be gathered …

7. Challenges • Effective formal specification framework • Describe the HW/SW system • Easy to understand • Unifying formal model for co-verification • Hardware and software are different • Use different formal representations

8. The Plan (I) Co-specification • Specify HW/SW system Formal Model • Büchi Pushdown System Model Checking

9. Co-specification for Driver/Device • Driver implementation • to be verified • Low-priority dispatch routines • High-priority Interrupt Service Routines (ISR)

10. A Hardware Model • Specified using Verilog semantics • Popular to hardware engineers • Non-blocking assignment • Atomicity in register state changes • A hardware model has • States described by registers • Initial states given by the initialization task • State transitions specified in Transaction Level Modeling (TLM)

11. begin hardware model // declare registers for hardware states reg [7:0] PortA, IntConfg; …… initial random; // a task that assigns non-deterministic values to registers if ( rand(0,1) ) begin // model the hardware behavior // low level triggers the interrupt if( (IntConfg == 8’h04) && ((PortA & 8’h01)==0) ) begin IntStatus <= 1; // set the interrupt status register INTR <= 1; // set the interrupt pending status to notify software end …… end else begin // simulate inputs from the environment // non-deterministically input to PortA if ( rand(0,1) ) PortA <= rand(8’h0, 8’hFF); ........ end end hardware model

12. HW/SW Interface WRITE_REGISTER_UCHAR(foo, 32)

13. Software to Hardware Interaction // Intermediate code that relates the read/write register function calls // to hardware state transitions UCHAR READ_REGISTER_UCHAR( PUCHAR register ) { switch ( register ) { case REG_PORTA: return ReadPortA(); case REG_PORTB: return ReadPortB(); case REG_PORTC: return ReadPortC(); …… case REG_STATUS: return ReadIntStatus(); return; default: RegAddressMismatch(); return; } }

14. Software Event Triggering Hardware State Transitions __atomic UCHAR ReadIntStatus( ) { // clear the interrupt status when read reg [7:0] retreg; retreg <= IntStatus; IntStatus <= 0; // return the register value to software return retreg; }

17. The Plan (II) • BPDS = BA ˣ LPDS • Represent concurrent • executions • Allow both HW and • SW models to be • Asynchronous • Synchronous Co-specification Formal Model • Büchi Pushdown System Model Checking

18. Büchi Automaton (BA) • A BA, • , the alphabet • , the finite set of states • , the set of state transitions • , the initial state • , the set of final states • The alphabet is defined on the states of PDS • PDS is the generatorof inputs to the BA WRITE_REGISTER_UCHAR(foo, 32)

19. Pushdown System (PDS) • A PDS, • , finite set of global states • , finite stack alphabet • , • , initial configuration • PDS doesn’t take any inputs • need to synchronize the PDS and BA …

20. Labeled PDS (LPDS) • We extend the PDS as • , the input alphabet • So the set of transition rules is • Now we can use our LPDS as a recognizer

21. Labeling Functions

25. The Plan (III) Co-specification Formal model • Büchi Pushdown System Model Checking • Verify BPDS model using • existing model checker

26. Co-verification Tool (CoVer) Driver Code Hardware Interface Model Abstraction Tool BPDS Model BPDS2PDS PDS Model Moped Model Checker Yes/No

27. Evaluation • Applied our approach to • an OSR Windows sample driver for a PCI device, and • the hardware interface model of the device • Found one previously undiscovered driver bug • A device driver architect has confirmed our finding • Designed a test benchmark for our model-checking algorithm

28. Conclusion • Our approach to co-verification • Co-specification • Co-verification model, BPDS • Evaluation has shown that our approach • can detect sophisticated bugs • is promising in improving the reliability of HW/SW interface implementations