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

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

Thomas BallMicrosoft Research

Joint work withJuncao Li and Fei XieDept. of Computer Science, Portland State UniversityVladimir Levin and Con McGarveyMicrosoft Corporation

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)

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 …

ChallengesEffective formal specification

frameworkDescribe the HW/SW system Easy to understand

Unifying formal model for co-verificationHardware and software are

differentUse different formal

representations

The Plan (I)

Co-specification

Model Checking

Formal ModelBüchi Pushdown System

Specify HW/SW system

Co-specification for Driver/Device

Driver implementation• to be verified• Low-priority dispatch

routines• High-priority Interrupt

Service Routines (ISR)

A Hardware ModelSpecified using Verilog semantics

Popular to hardware engineersNon-blocking assignment

Atomicity in register state changes

A hardware model hasStates described by registers Initial states given by the initialization taskState transitions specified in Transaction

Level Modeling (TLM)

10

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

HW/SW Interface

WRITE_REGISTER_UCHAR(foo, 32)

Software to Hardware Interaction

// Intermediate code that relates the read/write register function calls // to hardware state transitionsUCHAR 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; }}

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;}

The Plan (II)

Co-specification

Model Checking

Formal ModelBüchi Pushdown System

BPDS = BA ˣ LPDS• Represent concurrent

executions • Allow both HW and

SW models to be• Asynchronous• Synchronous

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 generator of inputs to the BA

),,,,( 0 FqQΒ Q

0qF

WRITE_REGISTER_UCHAR(foo, 32)

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

…

),,,,( 00 gGPG

*)()( GG

00 ,g

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

),,,,,( 00 gGIP

*)()( GIG

Labeling Functions

The Plan (III)

Co-specification

Model Checking

Formal modelBüchi Pushdown System

Verify BPDS model using existing model checker

Yes/No

Co-verification Tool (CoVer)

Hardware Interface

ModelDriver Code

Abstraction

Tool

BPDS Model

BPDS2PDS

PDS Model

MopedModel

Checker

EvaluationApplied 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

ConclusionOur 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