Formalizing Hardware/Software Interface Specifications Juncao Li Microsoft Corporation Joint work with Fei Xie Dept. of Computer Science, Portland State University Thomas Ball, Vladimir Levin and Con McGarvey

Why? Computer systems are pervasive One billion PCs had been sold by 2002 (cf. Wikipedia) Hardware (HW) and software (SW) are often manufactured separately Intel, HP, Microsoft, … Dependencies between HW and SW induce product risks Product quality affected by HW/SW interface issues Long product cycle Compatibility/sustainability issues

Design Stage Development Stage Post-release Stage Issues detected HW/SW Interface protocol Manual proof reading Draft English Document Design Stage Passed Devices or drivers Develop devices or drivers Published English Document Failed In-house testing Development Stage Passed Here is an example how HW/SW systems are designed, the English document is used in every stage. Stage 1. when the HW/SW interface protocols are designed, English document is used between different initiator companies. They have to proof-read the document to check the correctness of it. There is no automatic tools can be applied. Stage 2. During the development stage, HW/SW systems in various companies are developed based on the same English document. We can imagine one document issues can cause how much confusions and bugs. Stage 3. During the certification stage, the certification testing cases are developed based on the same English document. Released products Failed Certification: Conformance testing Post-release Stage Ship the product

Long product cycle! Software to Hardware Dependency English Document Device Prototype Device Driver Bugs, interface inconsistencies … Long product cycle!

Our Solution Synthesize a unified formal representation Hardware formally as Büchi Automaton (BA) Software formally as Labeled Pushdown System (LPDS) HW/SW interface: formally as Büchi Pushdown System (BPDS) = BA × LPDS Specification of HW/SW interface protocols In a C-like language (modelC) Map such specification to BPDS Validation techniques based on the specification Co-verification, co-simulation, conformance testing, etc. Where the specification is used as test harnesses/golden models modelC Language is actually …

Introduction Preliminaries Specification Where are we … Application Evaluation Conclusion Next, we would like to introduce the preliminaries of our work.

Büchi Automaton (BA) A BA, Acceptance condition on an input string , the alphabet , the finite set of states , the set of state transitions , the initial state , the set of final states Acceptance condition on an input string Visits at least one of the final states infinitely often The alphabet is defined on the states of LPDS LPDS is the generator of the inputs to BA WRITE_REGISTER_UCHAR(foo, 32) B accepts an infinite input string if and only if it has a run over the string that visits at least one of the final states infinitely often. The alphabet of BA is defined as a power set of the set of propositions that may hold on the states of LPDS

Labeled Pushdown System (LPDS) A LPDS, , the input alphabet , the finite set of states , the finite stack alphabet , set of transition rules , the initial configuration Say what global state is … y and w is not the same, … What a transition rule does is to modify the global states and replace the top of the stack with a string a symbols from the stack alphabet

Device/Driver Stack Function driver (e.g., mouse, network card) ISR DDI Software Hardware Bus driver (e.g., PCI, USB) Bus device (e.g., PCI, USB) Intermediate software layers Intermediate hardware layers ISR (Interrupt Service Routine) DDI (Device Driver Interface) Interrupt Signal Function driver (e.g., mouse, network card) (Read through the text on the slide would be fine.) Function device (e.g., mouse, network card)

Introduction Preliminaries Specification Where are we … Application Evaluation Conclusion Next, we would like to introduce the preliminaries of our work.

Specifying HW/SW Interface Protocols Software Model Dispatch Routines Hardware Model HW/SW Interface ISR BA I did some thing similar to DSF, I use the actual driver instead of a model of the driver. We apply our approach to the co-verification of device driver implementations with their device models I will give the definition of synchronous and asynchronous transition later LPDS Software model is composed of Low-priority dispatch routines High-priority Interrupt Service Routines (ISRs)

Two Key Concepts for Hardware Modeling Hardware Transaction Relative Atomicity

Hardware Transaction Transaction-level Modeling (TLM) Implementation details are abstracted away into high- level designs Hardware Transaction A hardware state transition Arbitrary long but finite sequence of clock-cycles Hardware Transaction Function A C (modelC) function for a set of state transitions Current state: state at the function entry Next state: state at the function exit Hardware transaction function: because we want to specify the hardware transaction using some programming language we are familiar with.

Relative Atomicity Model the concurrencies Two key ideas inside hardware between hardware and software Two key ideas Hardware transactions are atomic in the view of software ISRs are atomic to other lower-priority software routines

Hardware (Formal) Model Software Model Dispatch Routines Hardware Model HW/SW Interface ISR BA A transaction-level model Describes the desired hardware behavior When hardware and software are asynchronous

A Hardware Model The hardware model has Concurrency inside HW states as global variables Initial states given by the initialization function State transitions by the transaction functions Concurrency inside HW Non-deterministic interleaving // The transaction function of // the PIO-24 device model __atomic VOID atRun_DIO() { // non-deterministic choices switch ( choice() ) { // Update the port output case 0: RunPorts(); break; // Interrupt management case 1: RunInterrupt(); break; …… }

VOID RunInterrupt( ) { // Interrupt management if(g_DIORegs.IRQ.IRQENn == 0) { // if the interrupt is not enabled goto Exit; } if(g_DIORegs.CW.CWD4 != 1) { // If Port A is not configured as input …… if(g_DIORegs.IRQ.IRQCn == 0) { // Low level fires an interrupt if(g_DIORegs.A.D0 == 0) g_DIORegs.IRQST.IRQST1 = 1; } else { Exit: return;

Software (Formal) Model Software Model Dispatch Routines Hardware Model HW/SW Interface ISR LPDS Specify the desired operation sequences for software to control hardware

Software Output to Port A // software operations on outputting to Port A VOID Output2PortA ( UCHAR data ) { // write to Port A WRITE_REGISTER_UCHAR(REG_PORTA, data); // If Port A is configured as “input”, set it as “output” if ( g_SWState.CW.CWD4 == 1 ) { // software should maintain the I/O status of all ports g_SWState.CW.CWD4 == 0; WRITE_REGISTER_UCHAR(REG_CONFIG, g_SWState.CW.WholeByte); }

HW/SW Interface WRITE_REGISTER_UCHAR(foo, 32) Software Model foo = 32; Dispatch Routines Hardware Model HW/SW Interface ISR Response the interrupt in a timely fashion Interrupts In this use of our BPDS, interactions between hardware and software interface transitions are synchonous

BA consists of Part of the HW/SW Interface Driver Dispatch Routines HW Formal Model HW/SW Interface ISR BA I did some thing similar to DSF, I use the actual driver instead of a model of the driver. We apply our approach to the co-verification of device driver implementations with their device models I will give the definition of synchronous and asynchronous transition later We need to describe the HW/SW interface portion for BA

LPDS Consists of Another Part of the HW/SW Interface Driver Dispatch Routines HW Formal Model HW/SW Interface ISR BA I did some thing similar to DSF, I use the actual driver instead of a model of the driver. We apply our approach to the co-verification of device driver implementations with their device models I will give the definition of synchronous and asynchronous transition later LPDS We need to describe the HW/SW interface portion for LPDS

Software to Hardware Interaction // Intermediate code that connects the read/write register function calls // with the hardware interface registers VOID WRITE_REGISTER_UCHAR ( PUCHAR register, UCHAR data ) { switch ( register ) { case REG_PORTA: atWritePortA(data); return; case REG_PORTB: atWritePortB(data); return; case REG_PORTC: atWritePortC(data); return; …… case REG_STATUS: atWriteStatus(); return; default: RegAddressMismatch(); return; }

Software Event Triggering a Hardware Transaction Function __atomic VOID atWritePortA( UCHAR ucRegData ) { // If Port A is configured as an “input” port if (g_DIORegs.CW.CWD4 == 1) { // Write to the output register instead of the port g_DIOState.OutputRegA.ucValue = ucRegData; } else { // Otherwise, configured as an “output” port // Update both the port and the output register g_DIORegs.A.ucValue = ucRegData; } Now we are at the Hardware side!

Hardware Event Triggering Software Transitions // Invoked the ISR if an interrupt has been fired VOID RunIsr ( ) { __atomic { // check/prepare the precondition before invoking the ISR if ( (IsrRunning == TRUE) || (InterruptPending == FALSE) ) return; IsrRunning = TRUE; } DioIsr(); // Invoke the ISR // set both the hardware and software to proper status after ISR. IsrRunning = FALSE; InterruptPending = FALSE;

Execution Semantics of Relative Atomicity // software operations on outputting to Port A VOID Output2PortA ( UCHAR data ) { // write to Port A WRITE_REGISTER_UCHAR(REG_PORTA, data); // If Port A is configured as “input”, set it as “output” if ( g_SWState.CW.CWD4 == 1 ) { // software should maintain the I/O status of all ports g_SWState.CW.CWD4 == 0; WRITE_REGISTER_UCHAR(REG_CONFIG, g_SWState.CW.WholeByte); } while ( choice() ) { atRun_DIO(); RunIsr(); }

Introduction Preliminaries Specification Application Where are we … Evaluation Conclusion Next, we would like to introduce the preliminaries of our work.

Stage Development Post-release Design HW/SW Interface protocol Draft English Document Manual proof reading Issues detected Stage Development Published English In-house testing Develop devices or drivers Devices or drivers Failed Post-release Released products Certification: Conformance testing Passed Ship the product Automatic tool Formal Specification Formal Specification Co-verification tool Here is an example how HW/SW systems are designed, the English document is used in every stage. Stage 1. when the HW/SW interface protocols are designed, English document is used between different initiator companies. They have to proof-read the document to check the correctness of it. There is no automatic tools can be applied. Stage 2. During the development stage, HW/SW systems in various companies are developed based on the same English document. We can imagine one document issues can cause how much confusions and bugs. Stage 3. During the certification stage, the certification testing cases are developed based on the same English document.

Introduction Preliminaries Specification Application Evaluation Where are we … Introduction Preliminaries Specification Application Evaluation Conclusion Next, we would like to introduce the preliminaries of our work.

Summary of Formal Specification Specified four HW/SW interface protocols Formal Device Model and Formal Driver Model Discovered fifteen specification issues in English documents that have existed for years Some of the issues was even found in protocol pseudo code

Co-verification: Use Formal Models as the Harness Applied to five Windows drivers Open Systems Resources (OSR) drivers Microsoft drivers Proved twenty four properties Discovered twelve unknown bugs Bugs were found in every driver Could cause data loss, interrupt storm, etc.

Bug Summary All bugs One bug happens Three bugs happen involve interactions between driver and device One bug happens when driver does not initialize device correctly Three bugs happen when device interrupts driver Four bugs are due to the out-of-synchronization of driver and device Four bugs happen when driver mishandles device failures

Introduction Preliminaries Specification Application Evaluation Where are we … Introduction Preliminaries Specification Application Evaluation Conclusion Next, we would like to introduce the preliminaries of our work.

Conclusion and Future Work We have Presented an approach to formally specify HW/SW interface protocols Applied our approach to industry practice Evaluation result is promising Discovered many specification issues Discovered many driver bugs Future work Co-simulation Conformance testing

Thanks!

Compatibility/sustainability issues! Hardware to Software Dependency English Document New Device Prototype Existing Device Driver Stack Imagine we already have a software product existing in the market, e.g., Windows 7. Then, some hardware company wants to design a new hardware prototype that utilizes existing HW/SW interfaces, e.g., USB 2.0. If the device driver stack is 100% percent confirm to the English specification, then no problem. However, there are often deviations … Incompatibilities Compatibility/sustainability issues!