Automatic Synthesis of High-Assurance Device Drivers

GERNOT HEISER, NICTA, AustraliaLEONID RYZHYK, MICHAEL STUMM, University of Toronto, Canada

PAVOL CERNY, University of Colorado Boulder, USAALASTAIR F. DONALDSON, Imperial College London, UK

1 Executive summaryDevice drivers are hard to develop and are notoriouslyunreliable [13,20]. While constant innovation in the areaof electronic design automation has led to dramatic im-provements in the IC design process, device driver de-velopment practices have not changed much since thedays of mainframe computers. As a result, it is commonnowadays for a product release to be delayed by driverrather than silicon issues [42].

To address this long-standing problem, we proposea new driver development methodology that will allowfaster creation of device drivers with fewer defects. Theinnovation at the heart of our methodology is the au-tomatic synthesis of correct-by-construction devicedrivers from a formal model of the hardware device anda specification of the driver/OS interface.

Our methodology has the following crucial properties.• Dramatic reduction in cost of driver develop-

ment, maintenance and QA. This is achievedby synthesizing drivers automatically from existingdevice specifications provided by hardware design-ers as transaction-level device models (TLMs).

• Support for hardware/software co-design andco-verification. Our approach allows devicedrivers to be created, tested, and formally verifiedearly in the product design workflow, before thehardware device is available in silicon. The avail-ability of the device driver in turn facilitates evalu-ation and validation of the hardware design.

• Strong functional correctness guarantees. Ourcorrect-by-construction approach to synthesis,combined with formal verification to detect bugsin input specifications and the synthesis algorithm,yields a high degree of confidence in the resultingdevice driver code.

• Broad application. Our approach is applicable toa wide range of modern I/O devices, including SoCIP blocks, communication devices, media and stor-age adapters, etc.

Research vectors addressed

This project will primarily attack the following researchvectors identified in the Intel RFP.

• Driver synthesis This project will advance state ofthe art in game-based reactive synthesis resulting inthe first practical driver synthesis tool applicable toa wide range of complex I/O devices.

• Driver validation We combine synthesis and veri-fication to achieve a high degree of assurance thatthe produced drivers are functionally correct. Thisgoes well beyond what is possible with existingdriver analysis tools, which are limited to detectingspecific classes of defects.

• Hardware/software co-design & co-verificationBy reusing hardware device specifications in driversynthesis, we achieve tighter integration betweendriver and hardware design workflows to the ben-efit of both software and hardware designers.

Expected impact

This work will lead to a radical change in the way devicedrivers are developed. It will provide a solid scientificand engineering foundation that is missing in the cur-rent development practice, and thus enable the creationof consistently high-quality drivers with predictable, andfaster, development times.

Quantitatively, we require that our tools can syn-thesize and verify drivers for high-end devices within20 minutes, yielding code whose efficiency and size iswithin 10% of manually crafted drivers. We aim to re-duce overall driver development time from the currentaverage of 6-12 months to less than one month.

Team and partners

The investigatory team’s combination of complementaryskills covers the wide range of research areas neces-sary to execute this ambitious project. Principally, theseare Computer Systems (Heiser, Ryzhyk, Stumm), Pro-gram Synthesis (Cerny and Ryzhyk), Software Verifica-tion (Donaldson, Cerny and Ryzhyk) and Concurrency(Donaldson and Cerny). We have also secured the sup-port (see attached letter) of Byron Cook, Principal Re-searcher at Microsoft Research, who was a key player inMicrosoft’s SLAM project on device driver verification.

1

2 Background and details of proposedtechnology

2.1 State-of-the-art and its limitations

Device driver reliability problems have drawn a lot of at-tention in both industry and academia. Previous researchidentified several key sources of driver defects [13, 29,34, 36]. First, driver development is currently not wellintegrated into the hardware design process: driver writ-ers typically work from device data sheets provided byhardware designers, which are often ambiguous or in-complete, and are prone to errors. These flaws adverselyaffect the quality of resulting drivers. Further, driverdevelopment typically starts after hardware design hasbeen completed, putting driver development on the crit-ical path to product delivery and limiting the time thatcan be spent on driver quality assurance.

The second major source of device driver bugs is thecomplex interface between drivers and the OS. ModernOSs define complex rules on driver-OS interactions thatare neither well documented not stable across differentOS releases. Furthermore, the OS can invoke the driverfrom multiple concurrent threads, which leads to numer-ous possibilities for race conditions and deadlocks.

Previous research has made major progress in usingautomatic verification methods to detect, or prove ab-sence of, defects in driver code related to the driver-OSinterface [3,14,15,19,21]. While this is a major step for-ward, current work cannot detect defects in device man-agement code, which constitutes the core of any devicedriver, and does not scale to large device drivers whichmake extensive use of program features that are chal-lenging for verification, such as sophisticated pointermanipulation, indirect function calls and bit-level arith-metic. Existing work has thus had an important but mod-est impact on the quality of device drivers.

2.2 Overview of our methodology

We put forward a radically different approach to solv-ing device driver reliability problems. Instead of fixingor isolating bugs in existing drivers, we propose to au-tomatically derive correct-by-construction driver imple-mentations from device specifications. By reusing ex-isting device specifications created by hardware design-ers, this approach allows creating drivers early in theproduct design cycle and with minimal manual effort.To achieve strong functional correctness guarantees, wepropose formal techniques for automatically validatingthe synthesized driver.

Our proposed methodology comprises two main com-

OS spec Device spec (TLM)

Driver synthesis engine

Synthesized driver

Correctness proof

Proof checker

Complex driver written using high-assurance C subset

Verification engine

Correctness verified

Bug detected

Proof validated

Proof incorrect => fix synthesis engine

Figure 1: Overview of the driver synthesis methodology.

ponents, driver synthesis and driver verification, whichare illustrated graphically in Figure 1. We now summa-rize the role and contributions of each component.

Driver synthesis The core innovation underpinningour method is a technique and tool for automatic synthe-sis of correct-by-construction device drivers, indicatedby the driver synthesis engine in Figure 1. The key in-sight behind this innovation is that the problem of syn-thesizing device drivers from device specifications canbe precisely formalized using the apparatus of game-based reactive synthesis. To this end, we interpret in-teractions between the driver, the device, and the OS asa game, where in order to win the driver must satisfy anypossible sequence of OS requests given any feasible de-vice behavior. Driver synthesis then consists of findinga winning strategy in the game on behalf of the driver.

The synthesis process starts with two input specifica-tions: the device specification and the OS specification.The device specification is a transaction-level model ofdevice behavior created by hardware designers as part ofthe standard design workflow. The OS specification de-scribes the communication protocol between the driverand the OS. This specification is developed by driverframework designers and is generic across a class ofsimilar devices, e.g., Ethernet controller devices, thus asingle OS specification for a device class can be used tosynthesize many drivers for devices from this class.

Given the input specifications, the synthesis tool com-putes a winning driver strategy and generates a completedriver implementation in C. Optionally synthesis can beguided by user input to improve the structure of synthe-sized code, making it more more human readable andeasier to maintain.

The driver implementation synthesized at this step as-sumes a sequential OS environment that serializes allrequests to the driver. The next step in this project is

2

to automatically extend this sequential implementationwith synchronization code required to handle concurrentdriver invocations from multiple OS kernel threads, sat-isfying the requirement that invocations of a driver re-turn the same results in the multi-threaded setting asthey would if all the calls to the driver were serial-ized. Implementing this simple specification manuallyis difficult and error-prone. By synthesizing synchro-nization code automatically we fully harvest the bene-fits of synthesis—unburdening programmers from diffi-cult details of synchronization code, while letting themuse generic, reusable correctness specifications. In syn-thesis for concurrency, we will also focus on perfor-mance aspects, mainly by developing techniques thatminimize the necessity for locking and other synchro-nization primitives, but also by using quantitative per-formance models.

Driver verification Our driver synthesis techniquewill be designed to generate drivers that are correct-by-construction with respect to the input specifications.Correctness of the synthesized driver is guaranteed pro-vided that the input specifications are correct and thesynthesis tools have been implemented correctly. Wewill investigates methods for checking the latter, de-termining cases where bugs in the implementation ofour synthesis algorithm lead to defects in the synthe-sised device drivers. In addition, we will investigatelanguage- and tool-support for direct construction ofhigh-assurance device drivers: for especially complexand highly parallel devices, such as graphics adapters,direct driver synthesis may be out of scope. In thiscase we will provide a “high-assurance” subset of C, de-signed to facilitate formal verification, so that drivers forsuch devices can be written to high quality standards andchecked using rigorous tools.Verification of input specifications The correctness ofdrivers generated by our synthesis technique depends onthe validity of input specifications: the TLM descriptionof a device, and the description of OS interface specifi-cation. In this proposal we do not address the problemof checking input specification correctness. There is sig-nificant existing technology (especially within Intel) forTLM/RTL cross-checking. The OS interface specifica-tion is simpler than the device TLM and is therefore eas-ier to get right; on the other hand it is very hard to verify,as this specification is implemented by hundreds of thou-sands lines of low-level kernel code, therefore we regardformal validation of the OS interface specification is out-side the scope the proposed project.

Driver cross-verification Assuming correct input speci-fications, a bug can only be introduced in the synthesizeddriver due to a defect in synthesis tools. We will exploretwo complementary approaches to validating the resultsof synthesis. The first approach will use model check-ing to automatically check that the generated driver doesindeed implement a winning strategy in the game, andhence that it is correct with respect to the input specifi-cations. This is indicated by the verification engine pro-cess of Figure 1: the engine is used to analyse a driverpost-synthesis. The second, more complicated but po-tentially more reliable approach, consists of extendingour synthesis tools to produce a formal correctness proofof the synthesized driver. This proof can be validated bya theorem prover such as Isabelle [28] or Coq [6], as in-dicated by the proof checker process in Figure 1. Proofvalidation provides a strong guarantee that the driver iscorrect with respect to the device and OS specificationsthat were used as input to synthesis.

Verification and language support for development ofcomplex drivers We are confident that our novel syn-thesis techniques will be capable of generating driversfor a wide range of devices. Nevertheless, drivers forhighly complex and concurrent devices such as graphicsadapters will be difficult to obtain via synthesis alone. Tosupport the development of complex drivers for paralleldevices (see Figure 1) we will investigate language sup-port to allow such drivers to be expressed using a subsetof C that is “high-assurance” in the sense that it is de-liberately restricted for simplicity of coding and ease offormal analysis. The verification engine component ofFigure 1 will be extended with novel algorithms to ver-ify drivers written in this high-assurance language sub-set, with a particular focus on scalable reasoning aboutconcurrency.

2.3 Further background: TLMs

Transaction-level device models (TLMs) [9] are com-monly used in modern hardware design. A TLM de-scribes device operation in terms of high-level transac-tions rather than clock cycles. A transaction representsan event such as a bus transfer, a device configurationchange, or transmission of a network packet. Beingmuch faster to develop than RTL, TLMs enable rapidarchitectural exploration early in the design flow. Theyare also commonly used in building functional systemsimulators long before the device becomes available insilicon. Finally, TLMs are used at the RTL verificationstage, to ensure that the resulting design behaves accord-

3

ing to the model. Because TLMs operate at the level ofabstraction relevant to driver developers, they are idealfor use in driver synthesis. In particular, a TLM focuseson describing externally visible device behavior, ratherthan its internal architecture, and on wall-clock timingof device operations rather than cycle-accurate timing.

3 Detailed technical rationale, approach,and research plan

Our aim is to develop scalable algorithms for driver syn-thesis and verification. We will implement these algo-rithms in a practical driver synthesis toolkit and evaluatethem by synthesizing and verifying drivers for a vari-ety of I/O devices, ranging from simple integrated sen-sors and hardware accelerators to high-end devices suchas Intel Gigabit Ethernet controllers, Wi-Fi controllers,storage controllers, audio and graphics adapters.

We now present a detailed technical plan for theproject as three work packages: Guided Sequential Syn-thesis (WP 1), Synthesis for Concurrency (WP 2) andFormal Verification (WP 3). The work packages are re-lated and together constitute an ambitious plan of work.To reduce the risk of the project producing “all or noth-ing” results, the work packages are loosely coupled andhave been designed to generate independently usefuloutputs. Furthermore, as presented in our schedule inSection 4, the work packages have been designed to runconcurrently. Thus while we believe the expertise of ourhigh quality investigatory team make the project likelyto succeed in its aims, even a partial success will yieldtechniques that are highly relevant to industry.

WP 1. Guided Sequential Synthesis.Lead partners: NICTA and University of Toronto.This work package is devoted to guided synthesis, whichis at the core of our novel approach. The work packageis supported by WPs 2 and 3 which cater for concurrencyand high assurance, respectively.

The guided sequential synthesis tool will automate thetedious and error-prone task of implementing the driverlogic. The key insight behind our approach is that thistask can be naturally formalized as a game that the driverplays against the device. Goals in this game are set bythe OS via I/O requests to the driver. In order to com-plete the request, the driver must control the device toperform the requested I/O action. The driver forces statetransitions inside the device by reading or writing de-vice registers. However, not all device transitions are di-rectly controllable by the driver. Device-internal events,such as receiving of a network packet or occurrence of

an error condition are outside the driver’s control. Thesynthesis tool must find a winning strategy in the gameon behalf of the driver, that guarantees that the driveris able to satisfy all possible sequences of OS requestsunder any sequence of uncontrollable device transitionspermitted by the device specification.

By reformulating driver synthesis as a game, we openthe way to leveraging the rich theoretical and algorith-mic apparatus of reactive game theory. Turning this vi-sion into a practical tool requires addressing several fur-ther challenges.

Scalability challenges Real I/O devices exhibit rich in-ternal state and complex behavior. Synthesizing a driverfor such a device can, in the worst case, involve a pro-hibitively expensive exhaustive exploration of the statespace of the device model. To date, game-based synthe-sis algorithms have not been applied to problems com-parable in size and complexity to those arising in driversynthesis [30]. As a result, existing theory does not offera satisfactory solution to the state explosion problem.

In this work package we will develop a new tech-nique for combating the state explosion problem basedon abstraction. Abstraction-based techniques have rev-olutionized software verification [3], making it applica-ble to complex real-world systems. We believe that thisapproach will also prove fruitful in driver synthesis. Ab-straction allows eliminating irrelevant details from inputspecifications, focusing on the information relevant forthe task at hand.

Ideally, we would like to find the coarsest possible ab-straction that still contains enough information to com-pute a winning strategy for the driver or to prove thatsuch a strategy does not exist. We will obtain such anabstraction incrementally using a new abstraction re-finement algorithm. Starting from a very coarse initialabstraction, the algorithm computes progressively moreprecise abstractions of the game automaton. At everyiteration, it attempts to find a winning strategy in the ab-stract game. This can lead to three possible outcomes:(1) synthesis fails due to imprecise abstraction, (2) non-existence of a winning strategy is established, or (3) awinning strategy is found. In the first case, the algo-rithm identifies a set of transitions of the abstract gameautomaton that must be refined for synthesis to makeprogress. It then computes a more precise abstraction ofthese transitions and retries the synthesis step, thus start-ing a new iteration of the abstraction-refinement loop. Inthe second and third cases, the abstraction refinement al-gorithm terminates and returns either a failure (case 2)

4

or a computed winning strategy (case 3).

Usability challenges The second set of challenges is re-lated to the creation of a practical software developmentprocess around driver synthesis. To have serious impacton developer productivity our techniques must be highlyautomatic, yet they must allow the user to communicatetheir expert knowledge of device performance charac-teristics to generate highly optimized code. Similarly,the user should be able to guide synthesis towards theproduction of structured code that can be easily main-tained. When synthesis fails because of a mismatch be-tween input specifications, meaningful feedback must beprovided, helping the software developer to identify andrectify the issue.

Our answer to this challenge is guided synthesis. In-stead of synthesizing a concrete winning strategy, oursynthesis algorithm will produce the most general strat-egy, that contains all possible winning driver moves ineach state. As the code generator backend unwinds thisstrategy into a program control flow, the user can op-tionally control this process. Actions available to theuser at this point include choosing one of available win-ning moves in the current program location, rearrangingprogram statements, and outlining statements into func-tions. Importantly, the synthesis tool makes sure that anychoices made by the user remain within the most generalwinning strategy; hence user error cannot lead to bugsin the synthesized driver.

Our strategy for debugging synthesis failures due toinput specification mismatches is based on the use ofcounterexample strategies. Whenever the synthesis al-gorithm cannot find a winning strategy for the driver,it generates an explanation of the failure in the form ofa counterexample strategy. This strategy describes anenvironment behavior under which the driver is unableto win the game. The user explores the counterexam-ple strategy using an interactive debugging tool. Dur-ing the debugging session the user plays the expectedwinning driver strategy and the debugger responds withcounterexample transitions on behalf of the environ-ment. Through this interaction the user encounters anunexpected state of the game, from which the driver isunable to complete an OS request, providing insight intothe root cause of the mismatch.

Figure 2 shows the proposed architecture of the driversynthesis tool that we will design to address the abovechallenges. Each component of the tool corresponds toa task in this work package:

T1.1 Compiling HDLs to synthesis specifications. Wewill design a compiler to translate device TLMs ex-pressed in a hardware description language (HDL)to the internal specification language of the syn-thesis tool.

T1.2 Translation into game automata. We will definea translation of a device model (after conversionto our internal specification language) and an OSspecification into a game automaton, which com-pactly represents all game components.

T1.3 Abstraction and synthesis. These are the cen-tral components of the synthesis toolkit responsi-ble for computing a winning strategy for the driveror a counterexample strategy for the environment.They implement the abstraction refinement schemedescribed above.

T1.4 Debugging GUI. To help the user troubleshootsynthesis failures we will design a graphical formatfor tracing failures back to defects in input specifi-cations. The interface will allow interactive explo-ration of the counterexample strategy produced bythe synthesizer.

T1.5 Code generation. The final stage of synthesis is toconvert the winning strategy computed by the syn-thesizer into C source code under optional interac-tive user guidance. Starting from the initial state ofthe system, it unwinds the strategy into a programcontrol flow, translating winning driver actions intoC statements. In doing so, it aims to minimize theresulting control flow automaton by merging simi-lar states in order to avoid code bloat.

In T1.1 we will develop a compiler for a single HDL,chosen based on the availability of device specifica-tions in this language. One candidate is the WindRiverDML [40] modeling language, which ships along witha set of DML models for many Intel devices as part ofthe Simics simulation platform [39]. Support for addi-tional HDLs (SystemC, C++, SystemVerilog, etc.) canbe implemented later via additional frontend compilers.

Extensions Subject to time and resource availability,we will explore two further extensions of the basic syn-thesis tool described above. First, we will investigatesynthesis of hardened device drivers [22, 26]. A hard-ened driver is able to detect unexpected environment be-haviors, such as device malfunctions or OS errors, andtake appropriate recovery measures, e.g., aborting orretrying the current I/O operation, resetting the device,or logging the faulty input. Second, we will explore the

5

device TLM

device TLM

(internal)

OS speci cation

counterexample

strategy

winning

strategy

driver.c

Figure 2: Architecture of the sequential driver synthesis tool.

use of quantitative synthesis techniques [8,10,11] in de-vice driver synthesis. Quantitative synthesis allows syn-thesizing code that is not only functionally correct, but isalso optimal in terms of execution time, power consump-tion, memory footprint, or other criteria important to thedeveloper. While we expect strategies synthesized us-ing methods described so far to perform well in practice,further performance tuning can be achieved by assigningcosts to various driver and device operations and usingquantitative synthesis algorithms to generate optimal orclose-to-optimal implementations.

Related work Automatic game-based device driver syn-thesis was pioneered by two of the investigators (Ryzhykand Heiser) in their work on the Termite driver synthe-sis tool [35]. This research laid out the key principlesbehind the approach and demonstrated its feasibility.However, this proof-of-concept implementation lacked ascalable synthesis algorithm applicable to complex real-world devices and did not support synthesis from exist-ing device specifications. In this work package we willaddress these limitations, turning automatic driver syn-thesis into a practical and highly desirable alternative tothe conventional manual driver development process.

WP 2. Synthesis for Concurrency.Lead partner: University of Colorado Boulder.The Synthesis for Concurrency work package will de-velop techniques and tools to automatically synthesizedrivers that can be safely called concurrently from multi-ple OS kernel threads. The drivers produced in WP 1 as-sume a single-threaded environment, where each call toa driver is executed in isolation. However, contemporaryOS kernels are multi-threaded, and thus several threadscan invoke the driver concurrently. In order to preventprogram errors stemming from concurrency, synchro-nization between driver methods is necessary. There-fore, the next step in full functional synthesis of driversis to transform the driver code produced in WP 1 to make

seq. driver

from WP1

generic

specification

performance

modeldriver.c

T2.2

Figure 3: Synthesis for concurrency tool.

it work correctly in a multi-threaded environment. Thetransformation can be done for instance by adding locksor other synchronization primitives.

Synchronization code is an ideal target for synthesis.This claim is based on two observations. First, syn-chronization code is notoriously hard to implement anddebug, as witnessed by a large number of concurrency-related bugs in existing device drivers [13, 29, 34]. Sec-ond, correctness is easy to specify declaratively. Thereason is that one can often use generic (i.e., applicationindependent) specifications, such as deadlock-freedomor linearizability. A tool that synthesizes synchroniza-tion code will thus have a big effect on programmer pro-ductivity.

Related work. Synthesis for synchronization code isan area that has attracted considerable attention re-cently [12, 18, 37, 38]. These pioneering works on syn-thesis cannot be directly applied to device drivers. Thereasons are two-fold. First, code synthesis for devicedrivers has to take into account specific constraints im-posed by the OS on the device driver architecture. Forinstance, one cannot use common primitives for mutualexclusions, such as semaphores, in interrupt handlers (acore part of device drivers). Second, the previous workdoes not consider performance objectives in synthesis,

6

or considers only limited syntactic criteria that might(but are not guaranteed to) influence performance pos-itively. We propose to go beyond the previous work anddevelop new synthesis methods that do not suffer fromthese limitations.

The goal of the WP 2 is to produce a tool that takesthe sequential driver produced in WP 1 as input, and in-serts synchronization primitives to ensure that the driverbehaves correctly in the concurrent (multi-core) setting.The research proposed in this work package will focuson the following four tasks.

T2.1 Specifications for concurrency in drivers. We willintroduce specifications that are generic and thattake into account device driver architecture.

T2.2 Synthesis by code transformations. We will devisea synthesis algorithm that minimizes the number ofsynchronization primitives used.

T2.3 Performance-aware synthesis. Building on ourprevious work, we will develop quantitative syn-thesis methods for device drivers.

T2.4 Synchronization code generation. We will developcode generation techniques for device drivers thatrespect constraints by the OS on drivers.

The workflow of the proposed tool is in Figure 3. Wenow describe each part in more detail.Specifications for Concurrency in Drivers. Programsynthesis is most useful when it is much easier to saywhat needs to be done than to say how it should be done.That is, program synthesis is most useful when declar-ative specifications are easier to write than imperativeprograms. This is the case for concurrency in drivers. In-tuitively, the concurrency specification requires simplythat the invocations of the driver return the same resultsas they would if all the calls to the driver were serialized.In T2.1, we will develop generic specifications that cap-ture this intuition for broad classes of drivers, are sim-ple to write and use, but take into account all sources ofconcurrency in drivers, e.g., interrupts, top- and bottom-halves, and workqueues. This requires extending stan-dard correctness notions such as linearizability.Synthesis. We will develop synthesis algorithms forplacement of synchronization code, focussing on cor-rectness (T2.2) and performance (T2.3). There are twoprincipal inputs to the tool we plan to develop: (i) thedriver code produced in WP 1, which assumes a sequen-tial setting, and (ii) the generic specification produced inT2.1. The output of T2.2 and T2.3 is a driver that workscorrectly in concurrent setting, but uses atomic sections,

a synchronization primitive that marks parts of code thatis to be executed atomically. Atomic sections are desir-able as they are easy to reason about algorithmically, butthey are not provided by mainstream OS kernels — thepurpose of Task T2.4 is to implement them using com-mon kernel synchronization primitives.

In T2.2, the novel technical contribution is the de-velopment of semantics-preserving transformations ofsequential code that aid in synthesis of synchroniza-tion. Synchronization code (such as locks) can often bethought of as having no effect on sequential execution(i.e., it is semantics-preserving), but makes concurrentexecution safe. Generalizing this view, we propose toconsider a number of other semantics-preserving codetransformations. Such transformations will decrease theneed for the use of synchronization primitives, thus en-suring better performance. For instance, the tool mightobtain a correct driver with fewer locks, if it first rear-ranges the order of instructions in the driver code (if therearrangement does not change the sequential behaviorof the driver). We will use a counterexample-based ap-proach to synthesis. In a loop, we will first use an off-the-shelf tool to check if there is a concurrent executionleading to a bug (such as assertion violation). If there isno bug, we output the current code. If there is a bug, wewill transform the code in order to disallow the coun-terexample. The transformation can for instance be arearrangement of the order of instructions (in a way thatpreserves sequential correctness), or it can be insertionof atomic sections.

In T2.3, we will work on synthesizing highly perfor-mant code. In prior work we developed the first ap-proach for synthesizing concurrent programs with re-spect to both performance and correctness criteria [10]for finite-state programs. We propose to extend this ap-proach using our recent work on abstract interpretationfor quantitative objectives [11]. To quickly guide thesynthesis engine to well-performing solutions, we willinvestigate common synchronization patterns used bydriver developers. Such patterns are often chosen withperformance in mind, so using them in synthesis willimprove the quality of the synthesized code.

Synchronization code generation. The output fromT2.2 and T2.3 will be a correct driver code with atomicsections. The purpose of T2.4 is to implement atomicsections using synchronization code supported by thekernel, such as spinlocks, mutexes, RCU locks, etc. Thisgoal is not straightforward. For instance, in interrupthandlers, the use of semaphores, or other primitives that

7

my cause a process to block, is not allowed. Therefore,existing techniques for code synthesis cannot be used.We will develop algorithms for code generation that re-spect constraints given by device driver software archi-tectures, and are informed by the best practices fromcurrent driver development. To help achieve the latter,we will allow user feedback, where a user could flagsynchronization code as not suitable, and can suggestother synchronization primitives to use. This is an in-stance of our guided synthesis approach, the paradigmused throughout the project.

Our techniques for synthesising synchronization codewill rely on a technique for finding bugs in, or verify-ing, concurrent software. Early experiments with off-the-shelf techniques for this purpose [32] show promise,but suffer from scalability limitations. In WP 3 we willinvestigate technique for efficient analysis of concurrentdrivers, which will accelerate the techniques here forsynthesising synchronization code.

WP 3. Formal verification.Lead partner: Imperial College London.This work package is devoted to achieving strong for-mal guarantees that device drivers behave correctly. Thefocus is on analysis of both drivers generated by the syn-thesis techniques of WPs 1 and 2, which may be incor-rect due to bugs in the synthesis algorithm implementa-tion, and complex hand-written drivers that are beyondthe scope of our synthesis techniques. Furthermore, theefficient verification and bug-finding techniques for con-current device drivers developed in this WP will serve toaccelerate the techniques for synthesising concurrency-safe device drivers in WP 2.

T3.1 Device driver cross-verification. Apply modelchecking- and theorem proving-based formal veri-fication techniques to drivers generated by our syn-thesis tool

T3.2 Automatic proof generation. Extend the synthesistechniques of WPs 1 and 2 to facilitate the genera-tion of device driver correctness proofs that can beautomatically checked

T3.3 Verification and language support for complex,concurrent device drivers. Devise scalable tech-niques for verifying concurrent drivers, to acceler-ate synthesis for concurrency, and complex driversthat are beyond the reach of our synthesis algo-rithms

To avoid erroneous drivers resulting from bugs in oursynthesis implementation, T3.1 will investigate model

checking- and theorem proving-based techniques fordriver validation. We will build on prior work on de-vice driver verification by the Investigators [1, 2] andothers [4, 5, 41].

The techniques developed in T3.1 will be specificallygeared towards our synthesis setting, exploiting the guar-antee that synthesised drivers will use a restricted, cleansubset of C programming language, free from some ofthe complexity of low-level systems code which oftencauses formal verification techniques to fail.

Another strategy for validating our synthesis algo-rithms, discussed in Section 2.2, is a proof generationapproach. This is the focus of T3.2. The idea is that oursynthesis tool will generate both a driver implementa-tion and an associated proof of correctness. This proofis produced by capturing decisions made by the synthe-sis algorithm using formal logic. For example, wheneverthe algorithm chooses a certain winning action in a givenstate of the game, it records the fact that all possibledevice states reachable by taking this action are withinthe previously computed winning region, and hence thechoice of the action is correct.

We will extend the synthesis technique of WPs 1 and 2so that the proof of a winning strategy (certifying drivercorrectness) is generated as a proof script for a theoremprover such as Isabelle or Coq. This will allow gener-ated proofs to be automatically checked by Isabelle/Coq,yielding a very high degree of assurance that the synthe-sized driver is correct.

T3.3 will concentrate on verification techniques forhighly complex and concurrent drivers. This has twoaims: to produce stand-alone analysis techniques thatcan be directly applied to complex driver source code,and to serve as an efficient engine for the concurrency-aware synthesis techniques of WP 2. While we are con-fident that the synthesis techniques proposed in WPs 1and 2 will be capable of generating drivers for a widerange of devices, drivers for especially complex and con-current devices, such as graphics adapters, will be out ofscope. Furthermore, concurrency-aware synthesis, es-pecially generation of synchronization code (T2.4) de-pends on an efficient engine for finding bugs in, or prov-ing correctness of, concurrent driver code.

Our strategy for delivering scalable analysis tech-niques for complex and concurrent driver code has threestrands. First, for verification we will exploit recent ad-vances by Donaldson and collaborators in techniques forsource-level verification of highly parallel software [7,16, 17]. Second, for bug-finding we will employ tech-

8

niques for mitigating state-space explosion due to con-currency in a manner that preserves large classes of bugs,including context-bounded search [27] and concurrent-to-sequential program transformations [23]. Third, weacknowledge that full device driver verification is virtu-ally impossible to achieve for existing drivers written inC, hence we will investigate language support for writ-ing verifiable drivers. This will involve identifying a re-stricted subset of C that allows full driver functionality tobe expressed, but which features a conservative type sys-tem, limited pointer arithmetic (which together guaran-tee type safety), and specially managed dynamic mem-ory allocation. These restrictions will allow the verifierto make stronger assumptions when reasoning about ac-cess to shared data, simplifying the process of reasoningabout correct concurrency.

The combination of verification techniques and pro-gramming language support developed during this workpackage will complement the synthesis approach ofWPs 1 and 2, yielding high assurance device driver im-plementations.

Related work. In addition to the state-of-the-art modelchecking research cited throughout this section, previ-ous work on proof generating compilers [31, 33] is rel-evant to this work package. Such compilers produce, inaddition to the compiled code, a proof that this code iscorrect with respect to the source program. This proofis checked independently of the compiler by a theoremprover, thus ensuring that compiled code is correct. Intask T3.2 of this work package, we will develop a similartechnique applicable to game-based software synthesis.

Programming language support for systems softwaredevelopment has been investigated before, most notablyin the context of Microsoft’s Singularity OS project [24].We propose language support for writing verifiabledrivers in task T3.3. We argue that our approach ismore pragmatic than that of Singularity, allowing devel-opers to write drivers using standard C, simply restrict-ing the use of well-known dangerous and difficult to rea-son about language constructs in order to allow scalableverification.

4 Schedule, milestones, deliverables andevaluation criteria

Figure 4 presents a proposed schedule for the work pack-ages and tasks described in Section 3 over a three yearperiod. Key relationships between tasks are indicated bydashed arrows in the figure. PhD students at NICTA,Boulder and Imperial will work full time on the project,

as will Dr Ryzhyk. The tasks for which they will beprincipally responsible are indicated in the figure. Theother investigators will each devote around 10% of theirtime to the project, devoted to working with the teammembers on key algorithms and analyses.

Although aspects of WPs 2 and 3 depend on someoutputs from WP1, we have designed the tasks so thatit is possible for all work packages to commence simul-taneously. This reduces the risk associated with stronginter-work package dependencies, and means that eachinstitution will be able to start work on the project assoon as high quality PhD students are hired.

Milestones and deliverables

Milestone 1 (month 6): State-of-the-art survey. To en-able technology transfer and collaboration between siteswith differing expertise, and to quickly get PhD studentsworking on the project up to speed, we will jointly pro-duce a report describing the state-of-the-art in each areaof the project. This survey of relevant literature and opensource and commercial tools will also give Intel a widerperspective on the landscape of the project.Associated deliverable: Unified survey document, con-tributed to by all work packages.

Milestone 2 (month 12): Initial results for driver andhardware case studies. During year 1 we will gathera set of challenge benchmarks: practical case studies todrive and evaluate our novel research. By the end ofyear 1 our synthesis tool will be capable of synthesizingsequential and concurrent device drivers, and will be rel-atively feature-rich. The focus so far will be on correctsynthesis; synthesis of highly efficient drivers will be thefocus during years 2 and 3. We will seek feedback fromIntel on these case studies to ensure relevance to theirdevice driver roadmap.Associated deliverables: Three deliverables, one perwork package, each comprised of a report describing rel-evant case studies and initial techniques, and an alphadistribution of tools. We will also deliver a report de-scribing one or more global case studies, used to driveand evaluate our end-to-end solution: open source de-vice descriptions for which synthesis of high assurancedrivers will have high impact.

Milestone 3 (month 24): Prototype synthesis and veri-fication tools. By the end of year 2, we will deliver opensource prototype software tools for full driver synthesisand verifying drivers written in a high-assurance subsetof C, with documentation. These tools will be capableof handling a large subset of the case studies associated

9

Task 0 6 12 18 24 30 36 Key:

T1.1: Compiling hardware descriptions t NICTA-led task

T1.2: Translation into game automata t Toronto-led task

T1.3: Abstraction and synthesis n1 t

Boulder-led task

T1.4: Debugging GUI n2 Imperial-led task

T1.5: Code generation n2 "All hands" task

T2.1: Specifications for concurrency b1 Relationship between tasks

T2.2: Synthesis by code transformations b2

T2.3: Performance-aware synthesis b1 n1: NICTA PhD student

T2.4: Synchronization code generation b1,b2 n2: NICTA PhD student

T3.1: Device driver cross-verification i1 t: Leonid Ryzhyk at University of Toronoto

T3.2: Automatic proof generation i1 n2 b1: University of Colorado Boulder PhD student

T3.3: Verifying complex, concurrent drivers i2 b2: University of Colorado Boulder PhD student

i1: Imperial College London PhD student

Gathering case studies all

Applying technology to project-wide case studies all

Tool integration all

Months

Figure 4: Schedule for the work package tasks described in Section 3.

with Milestone 2. This will allow Intel to evaluate theproject outputs and provide feedback and guidance forthe final year.

Associated deliverables: Two separate tools: theguided synthesis engine, which is the combined resultsof WPs 1 and 2, and the driver verification engine devel-oped during WP 3.

Milestone 4 (month 36): Verification and synthesistools for high-end drivers. At the end of the project,we will deliver updated versions of the open source toolsthat are capable of handling a wide range of drivers anddevices. Our synthesis technique will be capable of syn-thesizing a wide range of complex drivers, and our ver-ification methods will scale to large hardware designs,demonstrating that the techniques can be broadly ap-plied. Due to the level of risk and scientific adventure as-sociated with our approach, aspects of some case studiesmay be beyond the scope of our final tool set. In thesecases we will document a set of open problems whichwill form the basis of further research.

Associated deliverables: Final versions of the synthe-sis and verification tools. The synthesis tool will beequipped with proof-generation facilities as described inWP 3. We will also deliver a report detailing our evalu-ation and documenting remaining open problems.

Collaboration and meetings

Collaboration between teams is essential for the successof the project. We will hold fortnightly teleconferencesinvolving two or more partners, in response to the projectrequirements. Monthly, the PIs will hold a joint tele-conference, where we will invite Intel collaborators, todiscuss the overall direction and success of the project.Annually we will hold an informal internal project work-shop involving all project members, to which Intel willbe invited. The purpose of the workshops will be to eval-uate the milestones reached and ensure tight integrationof techniques. To reduce travel costs, workshops will beco-located with top conferences in relevant areas. Ad-ditionally we will organize extended student visits be-tween partner sites to enable close collaboration.

Evaluation criteria

We now comment on how our proposed research meetsthe evaluation criteria described in the RFP.

Potential contribution and relevance to Intel. Intel de-vote significant effort to the design and implementationof device drivers. Our approach to automatic driver syn-thesis thus has the potential for major impact on Intel’sdevice driver process, significantly reducing the bottle-neck of driver development and consequently reducingproduct time-to-market. The techniques we design forTLM/RTL validation will also have high relevance forIntel: TLMs are used by hardware designers indepen-

10

dently of device driver development, and correctness ofthese models with respect to RTL is essential.

Innovation and non-incremental potential. Automaticsynthesis has been described as a “holy grail” for devicedriver development. Our guided synthesis approach willprovide largely automatic synthesis for complex devicedrivers with high assurance guarantees. If we are suc-cessful in achieving these aims this will constitute abreakthrough in the field. Our methodology is highlynon-incremental: it differs radically from the currentstate-of-the-art in device driver design and verification.

Objectives, milestones and success criteria. The goalsof our project are ambitious but the objective is simple:A highly automatic technique for synthesizing correct,efficient drivers from hardware and OS specifications.

The main success criterion is whether our approachwill ultimately be capable of synthesizing drivers for awide range of case-studies. In quantitative terms, werequire that our tools are able to synthesize and ver-ify drivers for high-end devices, such as Intel GigabitEthernet, SCSI, and Wi-Fi controllers, within 20 min-utes, with the performance and code size of synthesizeddrivers being within 10% of manually developed andtuned drivers. We further expect the overall driver devel-opment time to decrease from 6-to-12 months, commonin current industrial practice, to less than one month,when using our tools.

The plan of Section 3 breaks the project down intologically connected but loosely coupled tasks, scheduledas in Figure 4. The intermediate milestones described atthe start of this section have been designed to ensure thatprototype tools are built throughout the project; thesetools can be directly evaluated by Intel.

Qualification of participating researchers. The In-vestigatory Team is described in detail in Section 5.Our multi-partner consortium combines world-leadingexpertise in systems, verificaiton, synthesis and concur-rency, providing an excellent environment in which tomake breakthrough progress in this important area.

Cost effectiveness and cost realism. Our budget is pro-vided as an attachment to this proposal. Given the po-tential impact of our research for Intel, we believe thata total cost of $1,320,779 (or $1,124,986 without over-heads) is a valuable investment.

Potential for co-funding. This proposal is an excellentfit for the Intel RFP. In addition, we will seek fundingfrom national research councils to pursue research in re-lated areas which will be complementary and supportive

to the project. In particular, program synthesis researchhas recently been strongly supported by the US NSF,and research into system-level verification techniques isa stated growth area for funding by the UK Engineeringand Physical Sciences Research Council.

5 Investigator team

Our team has a unique combination of skills and expe-rience covering the full spectrum of theoretical and ap-plied topics required for this project.

Gernot Heiser, Leonid Ryzhyk, and Michael Stummwill lead the effort on WP1 with personnel consistingof Leonid Ryzhyk at the University of Toronto, and twograduate students at NICTA. Pavol Cerny will lead thework on WP2, with two graduate students working withhim at the University of Colorado Boulder. AlastairDonaldson will lead the research on WP3, working withtwo graduate students at Imperial College London.

Our team has a track record of successful relevantcollaboration between team members and with Intel.Ryzhyk led a joint project between NICTA and theOS Research Group at Intel Labs, developing a newtechnique for improving device driver quality based onhardware/software co-verification [36]. Donaldson hasworked with Heiser and Ryzhyk on static driver verifica-tion [1,2]. Cerny hosted a visit from Ryzhyk and Heiserat IST Austria in 2011 to collaborate on theoretical as-pects of driver synthesis, and has since collaborated withthem on synthesis for concurrency in OS code.

Prof Gernot Heiser (NICTA) leads the Software Sys-tems Research Group at NICTA and holds UNSWs JohnLions Chair for Operating Systems. Since 2011 he isa Scientia Professor (UNSWs term for laureate profes-sors). Heiser has a 20-year track record of research inoperating systems. His research group at UNSW andNICTA has built a number of research OSs and kernels,including the L4-embedded microkernel and the seL4microkernel, which is the first protected OS kernel witha complete formal proof of functional correctness. Histeam’s kernels achieved several still unbroken records oninter-process-communication performance.

In 2006, Gernot Heiser founded OK Labs, a Chicago-based startup with a Sydney-based engineering team.OK Labs commercialized L4-embedded, leading to itsdeployment in over 1.5 billion mobile devices to date.

Heiser’s research group has completed several influ-ential research projects on device driver reliability, in-cluding research on user-level device drivers [25], theDingo reliable device driver framework for Linux [34],

11

hardware/software co-verification (in collaboration withIntel) [36], and the pioneering work on automatic devicedriver synthesis [35]. This work has been published intop research venues and made significant impact in thecommunity. Heiser has been awarded the titles of Inno-vation Hero, the New South Wales Scientist of the Yearaward (2009) for the category Mathematics, Engineeringand Computer Science, and is listed as one of Australia’s100 most influential engineers.

Dr Leonid Ryzhyk (University of Toronto) is currentlya researcher at NICTA and a conjoint lecturer at UNSWin Sydney, Australia. In 2013 he will join the Depart-ment of Electrical and Computer Engineering at the Uni-versity of Toronto as a postdoctoral researcher. He holdsa PhD from UNSW.

Ryzhyk’s PhD and postdoctoral research has focusedon device driver reliability and in particular on the de-velopment of formal techniques for driver verificationand synthesis. Results of this work are published in topsystems research conferences, including SOSP, Eurosys,and ASPLOS. During his PhD Ryzhyk developed theDingo reliable device driver framework for Linux [34],which is centered around a formal language for speci-fying communication protocols between device driversand the OS. During the latter part of his PhD Ryzhykdeveloped Termite, the world’s first tool for automaticdevice driver synthesis [35]. This research identified thekey principles behind driver synthesis and demonstratedthe feasibility of this approach.

Prof Michael Stumm (University of Toronto) is a FullProfessor in the Department of Electrical and ComputerEngineering and the Department of Computer Scienceat the University of Toronto, Canada, where he has beena faculty member since 1987. Stumm was Director ofComputer Engineering from 1996–1998, and has grad-uated 18 PhD and 20 Masters students. Before joiningthe University of Toronto, Stumm pursued post-doctoralstudies at Stanford University.

Stumm’s primary research interests lie in the area ofsystems software, primarily for parallel systems, focus-ing on performance issues. He and his students devel-oped the Tornado operating system which was licensedto IBM and then jointly with IBM developed the K42 op-erating system. More recently, he developed a new oper-ating system call mechanism that, for example, increasesthe throughput of software servers, such as Apache andMySQL by 100% and 40%, respectively. He has pub-lished over 80 papers in leading journals and top-tiercomputer systems conferences (H-Index: 30). He holds

7 patents, with two additional patents pending.Stumm has co-founded two startups: he was CTO of

SOMA Networks, which at its peak had over 250 em-ployees, and until May 2012 was CEO of OANDA, thefirst company to bring currency trading to the retail mar-ket which now has a daily cash flow of about $10 billion.

Prof Pavol Cerny (University of Colorado Boulder)is an Assistant Professor at the University of Coloradoat Boulder. Before joining CU Boulder he was a post-doctoral researcher at IST Austria. He obtained his PhDin 2009 from the University of Pennsylvania. Cerny’sresearch interests currently center on program synthesis.His recent contributions include the techniques for quan-titative synthesis for concurrent programs. The tech-niques and the resulting tool was the first to take intoaccount performance objectives, in addition to correct-ness criteria, for synthesis of concurrent programs. Theresearch was published in top conferences in verification(CAV 2011) and programming languages (POPL 2013).

His other main research contributions include workon synthesis of component interfaces (POPL 2005), onnew foundational automata-theoretic model for programverification (POPL 2011), and on verification of concur-rent programs (CAV 2010). His paper (TACAS 2007)won a Microsoft Research Cambridge award for beststudent paper. His paper on synthesis was a finalist (oneof three) for a best paper award at EMSOFT 2012. Hewas a member of a multi-university team that performedsecurity evaluation of voting machines for the state ofOhio prior to 2008 US presidential elections. He led theefforts in static analysis of the back-end system.

Dr Alastair F. Donaldson (Imperial College London)is a Lecturer (Assistant Professor) in the Departmentof Computing at Imperial where he leads the Multi-core Programming Group. He is Scientific Coordina-tor and PI of CARP: Correct and Efficient Acceler-ator Programming, an eight-partner European Union-funded research project (total value: $ 3.6M, value forImperial: $780,000), and PI of the UK-funded projectScalable Automatic Verification of GPU Kernels (value:$170,000). Before joining Imperial Donaldson wasa Research Fellow at the University of Oxford work-ing with Prof Daniel Kroening. During fall 2011 hewas a Visiting Researcher at Microsoft Research, Red-mond, USA, and subsequently hired as a Consulting Re-searcher by Microsoft during 2012.

Donaldson’s research interests span two main areas:verification of system-level software and programmingmodels for multicore architectures, and has published

12

more than 40 peer-reviewed research papers in these ar-eas. His main contributions to verification (with col-laborators at Oxford, Imperial and Microsoft) includea technique for automatic analysis of DMA races inmulticore software [17], the first scalable predicate ab-straction technique for concurrent programs [16], and amethod for automatically checking that GPU kernels arefree from data races [7].

Collaboration with Microsoft Research

Prof Byron Cook is a Principal Researcher at MicrosoftResearch, Cambridge, UK and joint manager of the Pro-gramming Principles and Tools group. Cook was a keycontributor to Microsoft’s SLAM project on driver veri-fication. SLAM has been incorporated into Microsoft’sStatic Driver Verifier tool which ships with the WindowsDriver Development Kit, and is widely used by driverdevelopers. Cook will provide advice related to driverreliability, and plans to collaborate on the formal verifi-cation part of the project. Cook has provided a letter ofsupport for this proposal which is attached to this appli-cation.

References

[1] Sidney Amani, Peter Chubb, Alastair Donaldson,Alexander Legg, Leonid Ryzhyk, and Yanjin Zhu.Automatic verification of message-based devicedrivers. In SSV. EPTCS, 2012.

[2] Sidney Amani, Leonid Ryzhyk, Alastair F. Don-aldson, Gernot Heiser, Alexander Legg, and YanjinZhu. Static analysis of device drivers: we can dobetter! In APSys, page 8. ACM, 2011.

[3] Thomas Ball, Ella Bounimova, Byron Cook,Vladimir Levin, Jakob Lichtenberg, Con McGar-vey, Bohus Ondrusek, Sriram K. Rajamani, andAbdullah Ustuner. Thorough static analysis of de-vice drivers. In Eurosys, pages 73–85, Leuven,Belgium, April 2006.

[4] Thomas Ball, Ella Bounimova, Byron Cook,Vladimir Levin, Jakob Lichtenberg, Con McGar-vey, Bohus Ondrusek, Sriram K. Rajamani, andAbdullah Ustuner. Thorough static analysis of de-vice drivers. In EuroSys, pages 73–85. ACM, 2006.

[5] Thomas Ball, Vladimir Levin, and Sriram K. Raja-mani. A decade of software model checking withslam. Commun. ACM, 54(7):68–76, 2011.

[6] Y. Bertot, P. Casteran, G. Huet, and C. Paulin-Mohring. Interactive Theorem Proving and Pro-gram Development: Coq’Art: The Calculus of In-

ductive Constructions. Texts in Theoretical Com-puter Science. An EATCS Series. Springer, 2004.

[7] Adam Betts, Nathan Chong, Alastair F. Donaldson,Shaz Qadeer, and Paul Thomson. GPUVerify: averifier for GPU kernels. In OOPSLA 2012, 2012.

[8] Roderick Bloem, Krishnendu Chatterjee,Thomas A. Henzinger, and Barbara Jobstmann.Better quality in synthesis through quantitativeobjectives. CAV, pages 140–156, 2009.

[9] Lukai Cai and Daniel Gajski. Transaction levelmodeling: an overview. In CODES+ISSS, pages19–24, Newport Beach, CA, USA, 2003.

[10] Pavol Cerny, Krishnendu Chatterjee, Thomas Hen-zinger, Arjun Radhakrishna, and Rohit Singh.Quantitative synthesis for concurrent programs. InCAV, pages 243–259, 2011.

[11] Pavol Cerny, Thomas Henzinger, and Arjun Rad-hakrishna. Quantitative abstraction refinement. InPOPL, 2013 (to appear).

[12] S. Cherem, T. Chilimbi, and S. Gulwani. Inferringlocks for atomic sections. In PLDI, pages 304–315,2008.

[13] Andy Chou, Jun-Feng Yang, Benjamin Chelf, SethHallem, and Dawson Engler. An empirical studyof operating systems errors. In SOSP, pages 73–88, Lake Louise, Alta, Canada, October 2001.

[14] Edmund M. Clarke, Daniel Kroening, NatashaSharygina, and Karen Yorav. Predicate abstractionof ANSI-C programs using SAT. Formal Methodsin System Design, 25(2-3):105–127, 2004.

[15] Byron Cook, Andreas Podelski, and Andrey Ry-balchenko. Termination proofs for systems code.In PLDI, pages 415–426, Ottawa, Ontario, Canada,2006.

[16] Alastair Donaldson, Alexander Kaiser, DanielKroening, Michael Tautschnig, and Thomas Wahl.Counterexample-guided abstraction refinement forsymmetric concurrent programs. Formal Methodsin System Design, 2012. DOI: 10.1007/s10703-012-0155-3.

[17] Alastair F. Donaldson, Daniel Kroening, andPhilipp Rummer. Automatic analysis of dma racesusing model checking and k-induction. FormalMethods in System Design, 39(1):83–113, 2011.

[18] M. Emmi, J. Fischer, R. Jhala, and R. Majumdar.Lock allocation. In POPL, pages 291–296, 2007.

[19] Dawson R. Engler, Benjamin Chelf, Andy Chou,and Seth Hallem. Checking system rules using

13

system-specific, programmer-written compiler ex-tensions. In OSDI, pages 1–16, San Diego, CA,October 2000.

[20] Archana Ganapathi, Viji Ganapathi, and DavidPatterson. Windows XP kernel crash analysis.In LISA, pages 101–111, Washington, DC, USA,2006.

[21] Thomas A. Henzinger, Ranjit Jhala, Rupak Ma-jumdar, George C. Necula, Gregoire Sutre, andWestley Weimer. Temporal-safety proofs for sys-tems code. In CAV, pages 526–538, Copenhagen,Denmark, 2002.

[22] Intel Corporation. Device driver hardening andmanageability, April 2011.

[23] Akash Lal and Thomas W. Reps. Reducing con-current analysis under a context bound to sequen-tial analysis. Formal Methods in System Design,35(1):73–97, 2009.

[24] James R. Larus and Galen C. Hunt. The singularitysystem. Commun. ACM, 53(8):72–79, 2010.

[25] Ben Leslie, Peter Chubb, Nicholas FitzRoy-Dale,Stefan Gotz, Charles Gray, Luke Macpherson,Daniel Potts, Yueting (Rita) Shen, Kevin El-phinstone, and Gernot Heiser. User-level de-vice drivers: Achieved performance. Journalof Computer Science and Technology, 20(5):654–664, September 2005.

[26] Microsoft Corporation. Fault resilient drivers forLonghorn server, 2004.

[27] Madanlal Musuvathi and Shaz Qadeer. Itera-tive context bounding for systematic testing ofmultithreaded programs. In Jeanne Ferrante andKathryn S. McKinley, editors, PLDI, pages 446–455. ACM, 2007.

[28] Tobias Nipkow, Lawrence C. Paulson, and MarkusWenzel. Isabelle/HOL — A Proof Assistantfor Higher-Order Logic, volume 2283 of LNCS.Springer, 2002.

[29] Nicolas Palix, Gael Thomas, Suman Saha,Christophe Calves, Julia Lawall, and Gilles Muller.Faults in Linux: ten years later. In ASPLOS, pages305–318, Newport Beach, CA, USA, 2011.

[30] Nir Piterman, Amir Pnueli, and Yaniv Sa’ar. Syn-thesis of Reactive(1) designs. In VMCAI, pages364–380, January 2006.

[31] Arnd Poetzsch-Heffter and Marek Gawkowski.Towards proof generating compilers. ENTCS,132(1):37–51, May 2005.

[32] Shaz Qadeer. Poirot - a concurrency sleuth. InShengchao Qin and Zongyan Qiu, editors, ICFEM,volume 6991 of Lecture Notes in Computer Sci-ence, page 15. Springer, 2011.

[33] Martin Rinard. Credible compilers. Technical re-port, Cambridge, MA, USA, 1999.

[34] Leonid Ryzhyk, Peter Chubb, Ihor Kuz, and Ger-not Heiser. Dingo: Taming device drivers. In Eu-rosys, Nuremberg, Germany, April 2009.

[35] Leonid Ryzhyk, Peter Chubb, Ihor Kuz, EtienneLe Sueur, and Gernot Heiser. Automatic devicedriver synthesis with Termite. In SOSP, Big Sky,MT, USA, October 2009.

[36] Leonid Ryzhyk, John Keys, Balachandra Mirla,Arun Raghunath, Mona Vij, and Gernot Heiser.Improved device driver reliability through hard-ware verification reuse. In ASPLOS, NewportBeach, CA, USA, March 2011.

[37] A. Solar-Lezama, C. Jones, and R. Bodık. Sketch-ing concurrent data structures. In PLDI, pages136–148, 2008.

[38] M. Vechev, E. Yahav, and G. Yorsh. Abstraction-guided synthesis of synchronization. In POPL,pages 327–338, 2010.

[39] Wind River. Wind River Simics.http://www.windriver.com/products/simics/.

[40] Wind River. Wind River Simics Model Builder ref-erence manual. version 4.4, September 2010.

[41] Thomas Witkowski, Nicolas Blanc, Daniel Kroen-ing, and Georg Weissenbacher. Model checkingconcurrent linux device drivers. In ASE, pages501–504, 2007.

[42] Raj Yavatkar. Era of SoCs, presentation at the IntelWorkshop on Device Driver Reliability, Modelingand Synthesis, March 2012.

14