Appears in Proceedings of the 31st IEEE Symposium on Security & Privacy (Oakland), May 2010

Overcoming an Untrusted Computing Base:Detecting and Removing Malicious Hardware Automatically

Matthew Hicks, Murph Finnicum, Samuel T. KingUniversity of Illinois at Urbana-Champaign

Milo M. K. Martin, Jonathan M. SmithUniversity of Pennsylvania

AbstractThe computer systems security arms race between at-tackers and defenders has largely taken place in the do-main of software systems, but as hardware complexityand design processes have evolved, novel and potenthardware-based security threats are now possible. Thispaper presents a hybrid hardware/software approach todefending against malicious hardware.

We propose BlueChip, a defensive strategy that hasboth a design-time component and a runtime component.During the design verification phase, BlueChip invokesa new technique, unused circuit identification (UCI),to identify suspicious circuitry—those circuits not usedor otherwise activated by any of the design verificationtests. BlueChip removes the suspicious circuitry andreplaces it with exception generation hardware. The ex-ception handler software is responsible for providing for-ward progress by emulating the effect of the exception-generating instruction in software, effectively providinga detour around suspicious hardware. In our experi-ments, BlueChip is able to prevent all hardware attackswe evaluate while incurring a small runtime overhead.

1 IntroductionModern hardware design processes closely resemble thesoftware design process. Hardware designs consist ofmillions of lines of code and often leverage libraries,toolkits, and components from multiple vendors. Thesedesigns are then “compiled” (synthesized) for fabrica-tion. As with software, the growing complexity ofhardware designs creates opportunities for hardware tobecome a vehicle for malice. Recent work has demon-strated that small malicious modifications to a hardware-level design can compromise the security of the entirecomputing system [22].

Malicious hardware has two key properties thatmake it even more damaging than malicious software.First, hardware presents a more persistent attack vector.Whereas software vulnerabilities can be fixed via soft-ware update patches or reimaging, fixing well-crafted

hardware-level vulnerabilities would likely require phys-ically replacing the compromised hardware components.A hardware recall similar to Intel’s Pentium FDIV bug(which cost 500 million dollars to recall five millionchips) has been estimated to cost many billions of dollarstoday [7]. Furthermore, the skill required to replace hard-ware and the rise of deeply embedded systems ensurethat vulnerable systems will remain in active use after thediscovery of the vulnerability. Second, hardware is thelowest layer in the computer system, providing malicioushardware with control over the software running above.This low-level control enables sophisticated and stealthyattacks aimed at evading software-based defenses.

Such an attack might use a special, or unlikely, event totrigger deeply buried malicious logic which was insertedduring design time. For example, attackers might intro-duce a sequence of bytes into the hardware that activatesthe malicious logic. This logic might escalate privileges,turn off access control checks, or execute arbitrary in-structions, providing a path for the malefactor to takecontrol of the machine. The malicious hardware thusprovides a foothold for subsequent system-level attacks.

In this paper we present the design, implementa-tion, and evaluation of BlueChip, a hybrid design-time/runtime system for detecting and neutralizing ma-licious circuits. During the design phase, BlueChip flagsas suspicious, any unused circuitry (any circuit not acti-vated by any of the many design verification tests) anddeactivates them. However, these seemingly suspiciouscircuits might actually be part of a legitimate circuitwithin the design, so BlueChip inserts circuitry to raisean exception whenever one of these suspicious circuitswould have been activated. The exception handler soft-ware is responsible for emulating hardware instructionsto allow the system to continue execution. BlueChip’soverall goal is to push the complexity of coping withmalicious hardware up to a higher, more flexible, andadaptable layer in the system stack.

The contributions of this paper are:

• We present the BlueChip system (Sections 3 and 4),which automatically removes potentially malicious

1

circuits from a hardware design and uses low-levelsoftware to emulate around removed hardware.

• We propose an algorithm (Section 5), called unusedcircuit identification, for automatically identifyingcircuits that avoid affecting outputs during designverification. We demonstrate its feasibility (Sec-tion 6) for use in addressing the problem of detect-ing malicious hardware.

• We demonstrate (Sections 7, 8, and 9), using fully-tested malicious hardware modifications as testcases on a SPARC processor implementation oper-ating on an FPGA, that: (1) the system successfullyprevents three different malicious hardware modifi-cations, and (2) the performance effects (and hencethe overhead) of the system are small.

2 Motivation and attack modelThis paper focuses on the problem of malicious circuitsintroduced during the hardware design process. Today’scomplicated hardware designs are increasingly vulner-able to the undetected insertion of malicious circuitryto create a hardware trojan horse. In other domains,examples of this general type of intentional insertion ofmalicious functionality include compromises of softwaredevelopment tools [26], system designers inserting mali-cious source code intentionally [8, 20, 21], compromisedservers that host modified source code [11, 12], andproducts that come pre-installed with malware [1, 4, 25].Such attacks introduce little risk of punishment, becausethe complexity of modern systems and prevalence ofunintentional bugs makes it difficult to prove malice orto correctly attribute the problem to its source [27].

More specifically, our threat model is that a roguedesigner covertly adds trojan circuits to a hardware de-sign. We focus on two possible scenarios for such rogueinsertion. First, one or more disgruntled employees at ahardware design company surreptitiously and intention-ally inserts malicious circuits into a design prior to finaldesign validation with the hope that the changes willevade detection. The malicious hardware demonstratedby King et al. [22] support the plausibility of this sce-nario, in that only small and localized changes (e.g., toa single hardware source file) are sufficient for creatingpowerful malicious circuits designed for bootstrappinglarger system-level attacks. We call such malicious cir-cuits footholds, and such footholds persist even aftermalicious software has been discovered and removed,giving attackers a permanent vector into a compromisedsystem.

The second scenario is enabled by the trend toward“softcores” and other pre-designed hardware IP (intel-

lectual property) blocks. Many system-on-chip (SoC)designs aggregate subcomponents from existing com-mercial or open-source IP. Although generally trusted,these third-party IP blocks may not be trustworthy. Inthis scenario, an attacker can create new IP or modifyexisting IP blocks to add malicious circuits. The attackerthen distributes or licenses the IP in the hope that someSoC creator will incorporate it and include it in a fabri-cated chip. Although the SoC creator will likely performsignificant design verification focused on finding designbugs, traditional black-box design verification is unlikelyto reveal malicious hardware.

In either scenario, the attacker’s motivation could befinancial or general malice. If the design modificationremains undetected by final design validation and ver-ification, the malicious circuitry will be present in themanufactured hardware that is shipped to customers andintegrated into computing systems. The attacker hasachieved this without the resources necessary to actuallyfabricate a chip or otherwise attacking the manufacturingand distribution supply chain. We assume that only oneor a few individuals are acting maliciously (i.e., not theentire design team) and that these individuals are unableto compromise the final end-to-end design verificationand validation process, which is typically performed bya distinct group of engineers.

Our approach to detecting insertions of malicioushardware assumes analysis at the level of a hardwarenetlist or hardware description language (HDL) source.In the two scenarios outlined, this assumption is reason-able, as (1) design validation and verification is primarilyperformed at this level and (2) softcore IP blocks areoften distributed in HDL or netlist form.

We assume the system software is trustworthy andnon-malicious (although the malicious hardware mayattempt to subvert the overlying software layers).

3 The BlueChip approach

Our overall BlueChip architecture is shown in Figure 1.In the first phase of operation, BlueChip analyzes the cir-cuit’s behavior during design verification to identify can-didate circuits that might be malicious. Once BlueChipidentifies a suspect circuit, BlueChip automatically re-moves the circuit from the design. Because BlueChipmight remove legitimate circuits as part of the transfor-mation, it inserts logic to detect if the removed circuitswould have been activated, and triggers an exception ifthe hardware encounters this condition during runtime.The hardware delivers this exception to the BlueChipsoftware layer. The exception handling software is re-sponsible for recovering from the fault and advancing thecomputation by emulating the instruction that was exe-

2

!"# !"# !"# !"#

$%&'#()&%&#

$%&'#()&%&#

*+,%-./0#

*+,%-./0#

(a) Circuit designed (b) Attack inserted (c) Suspicious circuits identified and removed

(d) Hardware triggers emulation software

12#

design-time run-time

Figure 1: Overall BlueChip architecture. This figure shows the overall flow for BlueChip where (a) designers develophardware designs and (b) a rogue designer inserts malicious logic into the design. During design verification phase,(c) BlueChip identifies and removes suspicious circuits and inserts runtime hardware checks. (d) During runtime,these hardware checks invoke software exceptions to provide the BlueChip software an opportunity to advance thecomputation by emulating instructions, even though BlueChip may have removed legitimate circuits.

cuting when the exception occurred. BlueChip pushesmuch of the complexity up to the software layer, al-lowing defenders to rapidly refine defenses, turning thepermanence of the hardware attack into a disadvantagefor attackers.

BlueChip can operate in spite of removed hardwarebecause the removed circuits operate at a lower layer ofabstraction than the software emulation layer responsiblefor recovery. BlueChip software does not emulate theremoved hardware directly. Instead, BlueChip softwareemulates the effects of removed hardware using a sim-ple, high-level, and implementation-independent spec-ification of hardware, i.e., the processor’s instruction-set-architecture specification. The BlueChip softwareemulates the effects of the removed hardware by emu-lating one or more instructions, updating the processorregisters and memory values, and resuming execution.The computation can generally make forward progressdespite the removed hardware logic, although softwareemulation of instructions is slower than normal hardwareexecution.

In some respects our overall BlueChip system resem-bles floating point instruction emulation for processorsthat omit floating point hardware. If a processor de-sign omits floating point unit (FPU) hardware, floatingpoint instructions raise an exception that the OS han-dles. The OS can emulate the effects of the missinghardware using available integer instructions. Like FPUemulation, BlueChip uses software to emulate the ef-fects of missing hardware using the available hardwareresources. However, the hardware BlueChip removes isnot necessarily associated with specific instructions and

can trigger BlueChip exceptions at unpredictable statesand events, presenting a number of unique challengesthat we address in Section 4.

4 BlueChip designThis section describes the design of BlueChip. We dis-cuss the BlueChip hardware component (Section 4.1),the BlueChip software component (Section 4.2), andpossible alternative architectures (Section 4.3). Section 5discusses our algorithm for identifying suspicious cir-cuits and Section 6 describes how BlueChip uses thesedetection results to modify the hardware design.

We present general requirements for applyingBlueChip to hardware and to software, but we describeour specific design for a modified processor and recoverysoftware running within an operating system.

4.1 BlueChip hardwareTo apply BlueChip techniques, a hardware componentmust be able to meet three general requirements. First,BlueChip requires a hardware exception mechanism forpassing control to the software. Second, BlueChip mustprevent modified hardware state from committing whenthe hardware triggers a BlueChip exception. Third, toenable recovery the hardware must provide software ac-cess to hardware state, such as processor register valuesand other architecturally visible state.

Processors are well suited to meet the requirementsfor BlueChip because they already have many of the

3

mechanisms BlueChip requires. Processors provide easyaccess to architecturally visible states to enable con-text switching, and processors have existing exceptiondelivery mechanisms that provide a convenient way topass control to a software exception handler. Also,most processors support precise exceptions that includea lightweight recovery mechanism to prevent committingany state associated with the exception. As a result, weuse existing exception handling mechanisms within theprocessor to deliver BlueChip exceptions.

One modification we make to current exception se-mantics is to assert BlueChip exceptions immediately in-stead of associating them with individual instructions. Incurrent processors, many exceptions are associated witha specific instruction that caused the fault. However, inBlueChip it is often unclear which individual instructionwould have triggered the removed logic. Thus, BlueChipasserts the exception immediately, flushes the pipeline,and passes control to the BlueChip software.

4.2 BlueChip software

The BlueChip software is responsible for recoveringfrom BlueChip hardware exceptions and providing amechanism for system forward progress. This re-sponsibility presents unusual design challenges for theBlueChip software because it runs on a processor thathas had some portions of the design removed, thereforesome features of the processor may be unavailable to theBlueChip exception handler software.

To handle BlueChip exceptions, BlueChip uses a re-covery technique where the BlueChip software emu-lates faulting instructions to carry out the computa-tion. The basic emulation strategy is similar to aninstruction-by-instruction emulator, where for each in-struction, BlueChip software reads the instruction frommemory, decodes the instruction, calculates the effectsof the instruction, and commits the register and memorychanges (Figure 2). By emulating instructions in soft-ware, BlueChip skips past the instructions that use theremoved hardware, duplicating their effects in software,providing the opportunity for the system to continuemaking forward progress despite the missing circuits.

One problem with our first implementation of thisbasic strategy was that our emulation routines sometimesdepended on removed hardware, thus causing unrecov-erable recursive BlueChip exceptions. For example,the “shadow-mode attack” (Section 7) uses a “bootstraptrigger” that initiates the attack. The bootstrap triggercircuit monitors the values going into the data cache andenables the attack once it observes a specific value beingstored in memory. This specific value will always triggerthe attack regardless of the previous states and eventsin the system. After BlueChip identified and removed

!"#$%&&&$

'$

()#$&*+$

(,#$

(-#$&*,$

'$

!./0122/.$

33$415$.146251.2$

.142$7$8./0122/.9.142:;$

33$<150=$6>25.?0@/>$

6>25$7$A:.142B!"C;$

33$D10/D1$/81.E>D2$

:/8F$.DF$.2%F$.2+;$7$D10/D1:6>25;$

6<:$/8$77$G(;$H$

$$$$33$1*10?51$6>25.?0@/>$

$$$$.142B.DC$7$.142B.2%C$I$.142B.2+C$

$$$$.142B!"C$J7$,$

K$1L21$6<:$/8$77$MNO;$H$

$$$$'$

K$

'$

33$0/PP65$.142$5/$8./0122/.$

!"#$!""#$

'$

()#$&*+$

(,#$"%&$

(-#$&*,$

'$

!./0122/.$

%&&&#$/.$.)F$.-F$.,$

Figure 2: Basic flow for an instruction-by-instructionemulator. This figure shows how a software emulatorcan calculate the changes to processor registers inducedby an or instruction.

the attack circuits, the BlueChip hardware triggered anexception whenever the software attempted to store theattack value to a memory location. Our first implemen-tation of the store emulation code simply re-issued astore instruction with the same address and value toemulate the effects of the removed logic, thus creatingan unrecoverable recursive exception.

To avoid unrecoverable recursive BlueChip excep-tions, we emulate around faulting instructions by pro-ducing semantically equivalent results while avoidingBlueChip exception states. For ALU operations, we mapthe emulated instructions to an alternative set of ALUoperations and equivalent, but different, operand values.For example, we implement or emulation using a seriesof xor, and nand instructions rather than executing anor to perform OR operations (Figure 3). For load andstore instructions we have somewhat less flexibility be-cause these instructions are the sole means for perform-ing I/O operations that access off-processor memory.However, we do perform some transformations, such asemulating word sized accesses using byte sized accessesand vice versa.

4.3 Alternative designsIn this section we discuss other possible designs andsome of the trade offs inherent in their design decisions.

4

Add!

Or r3, r5, r4!

Sub!

…!

…!

Load regs[3], t1!

Load regs[5], t2!

Xor t1, 0xffffffff, t1!

Xor t2, 0xffffffff, t2!

Nand t1, t2, t3!

Store t3, regs[4]!

// update pc and npc!

// commit regs!

!"#$%&'()*+,-./$)

012)

032)

042)

052)

Figure 3: BlueChip emulation. This figure shows howBlueChip emulates around removed hardware. First, (1)the software executes an or instruction, (2) which causesa BlueChip exception. This exception is handled by theBlueChip software, (3) which emulates the or instructionusing xor and nand instructions (4) before returningcontrol to the next instruction in the program.

BlueChip delivers exceptions using existing processorexception handling mechanisms. One alternative couldbe adding new hardware to deliver exceptions to theBlueChip software component. In our current design,BlueChip is constrained by the semantics of the exist-ing exception handling mechanisms and cannot deliverexceptions when software disables interrupts.

An alternative approach could have been to add extraregisters and logic to the processor to allow BlueChip tosave state and recover from BlueChip exceptions, evenwhen the software disables interrupts. However, thisadditional state and logic would have required encodingseveral implementation-specific details of the hardwaredesign into BlueChip, potentially making it more diffi-cult to insert BlueChip logic automatically. Given theinfrequency of disabling interrupts for long periods inmodern commodity operating systems, we decided touse existing processor exception delivery mechanisms.If a particular choice of hardware and software makesthis unacceptable, there are several straightforward ap-proaches to addressing this issue, such as using a hyper-visor with some additional support for BlueChip.

BlueChip emulates around BlueChip exceptions byusing different instructions to emulate computations thatdepend on hardware removed by BlueChip. In ourcurrent design we implement this emulation techniquemanually for all instructions in the processor’s instruc-tion set. However, we still rely on portions of the OSand exception handling code to save and restore the

system states we emulate around. It might be possiblefor these instructions to inadvertently invoke an unrecov-erable BlueChip exception by executing an instructionthat causes a BlueChip exception. One way to avoidunrecoverable BlueChip exceptions could be to modifythe compiler to emit only a small set of Turing completeinstructions for the BlueChip software, such as nand,load, and store instructions. Then we could focusour testing or formal methods efforts on this subset ofthe instruction set to decrease the probability of an un-recoverable BlueChip exception. This technique wouldlikely make the BlueChip software slower because itpotentially uses more instructions to carry out equivalentcomputations, but it could decrease the occurrence ofunrecoverable BlueChip exceptions.

5 Detecting suspicious circuits

This section describes our detection algorithm for identi-fying suspicious circuits automatically within a hardwaredesign. We focus on automatically detecting potentiallymalicious logic embedded within the HDL source codeof a design, and we perform our detection during thedesign phase of the hardware design life cycle.

Our goal is to develop an algorithm that identifiesmalicious circuits without identifying benign circuits. Inaddition, our technique should be difficult for an attackerto avoid, and it should identify potentially malicious codeautomatically without requiring the defender to developa new set of design verification tests specifically for ournew detection algorithm.

Hardware designs often include extensive design veri-fication tests that designers use to verify the functionalityof a component. In general, test cases use a set of inputsand verify that the hardware circuit outputs the expectedresults. For example, test cases for processors use asequence of instructions as the input, with the processorregisters and system memory as outputs.

Our approach is to use design verification tests to helpdetect attack circuits. If an attack circuit contaminatesthe output for a test case, the designer would know thatthe circuit is operating out-of-spec, potentially detect-ing the attack. However, recent research has shownhow hardware attacks can be implemented using smallcircuits that are designed not to trigger during routinetesting [22]. This evasion technique works by guard-ing the attack circuit with triggering logic that enablesthe attack only when it observes a specific sequence ofevents or a specific data value (e.g., the attack triggersonly when the hardware encounters a predefined 128-bit value). This attack-hiding technique works becausemalicious hardware designers can avoid perturbing out-puts during testing by hiding deep within the vast state

5

!"

#"

!"

#"

!"

#"

$%%&"

$%%&"

'()*+"

'()*+"

,"

-"

./0"

1023!4"

1023#4"

X <= (Ctl(0) = ‘0’) ? Good : Attack!

Y <= (Ctl(1) = ‘0’) ? Good : Attack!

Out <= (Ctl(0) = ‘0’) ? X : Y!

1023!4"

Figure 4: Circuit diagram and HDL source code for amux that can pass code coverage testing without enablingthe attack. This figure shows how a well-crafted mux canpass coverage tests when the appropriate control states(Ctl(0) and Ctl(1)) are triggered during testing. Controlstates 00, 01, and 10 will fully cover the circuit withouttriggering the attack condition.

space of a design,1 but can still enable attacks in thefield by inducing the trigger sequence. Our proposal is toconsider circuits suspicious whenever they are includedin a design but do not affect any outputs during testing.

5.1 Straw-man approach: code coverage

One possible approach to identifying potentially mali-cious circuits could be to use code coverage. Codecoverage is defined as the percentage of lines of code thatare executed, out of those possible. Because attackerswill likely try to avoid affecting outputs during testing,highlighting uncovered lines of code seems like a viableapproach to identifying potentially malicious circuits.

An attacker can easily craft circuits that are coveredcompletely by testing, but never trigger an attack. Forexample, Figure 4 shows a multiplexer (mux) circuit thatcan be covered fully without outputting the attack value.If the verification test suite includes control states 00, 01,and 10, all lines of code that make up the circuit willbe covered, but the output will always be “Good”. Weapply this evasion technique for some of the attacks we

1A processor with 16 32-bit registers, a 16k instruction cache, a64k data cache, and 300 pins has at least 2655872 states, and up to2300 transition edges.

// step one: generate data-flow graph

// and find connected pairs

pairs = {connected data-flow pairs}

// step two: simulate and try to find

// any logic that does not affect the

// data-flow pairs

foreach simulation clock cycle

foreach pair in pairs

if the sink and source not equal

remove the pair from the pairs set

Figure 5: Identifying potentially malicious circuits usingour UCI algorithm.

!""#$

%&'()$

*$

+,-$

.$

Figure 6: Data-flow graph for mux replacement circuit.

evaluated (Section 7) and find that it does evade codecoverage detection.

Although code coverage can complicate the attacker’stask of avoiding testing, this technique can be defeatedbecause code coverage misses the fundamental propertyof malicious circuits: attackers are likely to avoid af-fecting outputs during testing, otherwise they would becaught. Instead, what defenders need is a technique thatzeros in on this property to identify potentially maliciouscircuits more reliably.

5.2 Unused circuit identification

This section describes our algorithm, called unused cir-cuit identification (UCI), for identifying potentially ma-licious circuits at design time. Our technique focuseson identifying portions of the circuit that do not affectoutputs during testing.

To identify potentially malicious circuits, our algo-rithm performs two steps (Figure 5). First, UCI creates adata-flow graph for our circuit (Figure 6). In this graph,nodes are signals (wires) and state elements; edges in-dicate data flow between the nodes. Based on this data-flow graph, UCI generates a list of all signal pairs, ordata-flow pairs, where data flows from a source signal toa sink signal. This list of data-flow pairs includes both

6

direct dependencies (e.g., (Good, X) in Figure 6) andindirect dependencies (e.g., (Good, Out) in Figure 6).

Second, UCI simulates the HDL code using designverification tests to find the set of data-flow pairs whereintermediate logic does not affect the data that flowsbetween the source and sink signals. To test for this con-dition, at each simulation step UCI checks for inequalityfor each of our remaining data-flow pairs. If the elementsof a pair are not equal, this implies, conservatively, thatthe logic in between the two pairs has an effect on thevalue, thus we remove pairs with unequal elements fromour data-flow-pairs set. For registers, UCI accountsfor latched data by maintaining a history of simulationvalues, allowing it make the appropriate comparison fortracking signal propagation.

After the simulation completes, UCI has a set of re-maining data-flow pairs where the logic in between thepairs does not affect the signal value from source to sink.In other words, we could replace the intermediate logicwith a wire, possible including some delay registers, andit would not affect the overall behavior of the circuit inany way for our design verification tests.

Consider how this algorithm works for the mux-replacement circuit shown in Figure 4:

1. UCI creates the initial set of data-flow pairs, whichfor our circuit is (Good,X), (Attack,X), (Good,Y),(Attack,Y), (Good,Out), (Attack,Out), (X,Out), and(Y,Out).

2. UCI considers the first simulation step where thecontrol signals are 00 and the output is Good, X isGood, and Y is Good. This removes (Attack,X),(Attack,Y), and (Attack,Out).

3. UCI considers the second simulation step where thecontrol signals are 01 and the output is Good, X isGood, and Y is Attack. This removes (Good,Y) and(Y,Out).

4. UCI considers the third simulation step where thecontrol signals are 10 and the output is Good, X isAttack, and Y is Good. This removes (Good,X) and(X, Out).

5. UCI finishes the simulation and is left with(Good,Out) in the list of data-flow pairs where inter-mediate logic does not affect the signal propagation.

The resulting output from UCI for this exampleidentifies the malicious circuit without identifying anyadditional signals. Because it systematically identi-fies circuits that avoid affecting outputs during testing,BlueChip connects the “Good” signal directly to the“Out” signal, thus removing the malicious elements fromthe design.

5.3 UCI limitations

In Section 9 we show that UCI successfully identifies themalicious circuits for the hardware-level footholds wedeveloped. In this section we discuss ways an attackercould hide malicious circuits from UCI.

First, an attacker could include malicious test casesthat check attack states incorrectly. By including thesemalicious test cases in the design verification test suitean attacker could fool the system designer into thinkingthat the out-of-spec modifications are in fact in-spec, thusslipping the attack past UCI. However, design verifica-tion tests work at a higher level of abstraction, making iteasier for system designers to verify the results indepen-dently. In fact, the BlueChip software includes code forinstruction-level emulation of the processor’s instructionset, and we use this emulation code on our test cases toverify that the test suite checks states correctly.

Second, an attacker could avoid UCI by crafting mali-cious circuits that affect unchecked outputs. Uncheckedoutputs could arise from incomplete test cases or fromunspecified output states. For example, the memorymodel in the SPARC processor specification providesfreedom for an implementation to relax consistency be-tween processors in a multi-processor system [24]. Thistype of implementation-specific behavior could be usedby an attacker who affects outputs that might be difficultfor a testing program to check deterministically, thuscausing malicious circuits to affect outputs and avoid ouranalysis. However, this evasion technique requires theattacker to trigger the attack during design verification,thus tests that check implementation-specific states andevents could detect the foothold directly.

Third, to simplify the analysis of the HDL source,our current UCI implementation excludes mux controlsignals from the data-flow graph. If an attacker could useonly mux control signals to modify architecturally visi-ble states directly, UCI would miss the attack. However,this limitation is only an artifact of our current imple-mentation and would likely be remedied if we includedmux control signals in our analysis.

6 Using UCI results in BlueChip

This section discusses how BlueChip uses the resultsfrom UCI to eliminate the effects of suspicious circuits.UCI outputs a set of data-flow pairs, where each pair hasa source element, a sink element, and a delay element.Conceptually, the source and the sink element can beconnected directly by a wire containing delay number ofregisters, effectively short circuiting the signals with adelay line. This removes the effects of any intermediatelogic between the source and the sink. BlueChip imple-

7

!"#$

%&'()*$

+,+-./0'$

%1*2()*$ 30)2$14$50)&6'$

!"#$

%&'()*$

+,+-./0'$

%1*2()*$ 30)2$14$50)&6'$

7+&%)8$9%&'()*:$%1*2()*;$

<=$)*/>?*0$ >?*0/0@$

rout.su <= attack_en ? 1 : rin.su! su_blue <= attack_en ? 1 : rin.su!rout.su <= rin.su!blue_ex <= su_blue != rin.su !

(a) UCI identifies attack (b) BlueChip transforms HDL to remove attack

Figure 7: HDL code and circuit diagram for HDL transformations BlueChip makes to remove an attack from a design.This figure shows (a) the original design where an attacker can transition the processor into supervisor mode byasserting the attack_en signal. During design verification, UCI detects that the value for rout.su always equalsrin.su, thus identifying the mux as a candidate for removal. Part (b) shows how BlueChip removes this logic byconnecting rin.su to rout.su directly and adds exception notification logic to notify software of any inconsistenciesat runtime.

ments this short-circuit by performing a source-to-sourcetransformation on the design’s HDL source code.

Once UCI generates a set of data-flow pairs, the pairsare fed into the BlueChip system (transformation pic-tured in Figure 7). BlueChip takes these pairs as aninput and replaces the suspicious circuits by modifyingthe HDL code using three steps. First, BlueChip createsa backup version of each sink in the list of pairs. Thebackup version of a signal holds the value that wouldhave been assigned to the signal in the original circuit.Second, BlueChip adds a new assignment to the originalsignal. The value assigned to the original signal is simplythe value of the source element in the pair, creating ashort circuit between the source and the sink. The restof the design will see this short-circuited value, whilethe BlueChip exception generation hardware sees thebacked-up version. The third and final step consists ofadding the BlueChip exception generation logic to thesource file. This circuit compares the backed-up value ofthe sink element with the source value. BlueChip gener-ates an exception whenever any of these comparisons arenot true. When a BlueChip exception occurs, it signalsthat the hardware was about to enter a state that was notseen during testing. From here, the BlueChip software isresponsible for making forward progress.

The HDL transformation algorithm also must handlemultiple data-flow pairs that share the same sink signalbut have different sources. This situation could poten-

tially cause problems for BlueChip because it is unclearwhich source signal to short-circuit to the original sinksignal. Our solution is to pick one pair for the sink signalassignment, but include exception generation logic for allpairs that share the same sink element. This means thatall violations are detected, but the sink may be shortedwith the source that caused the exception. This untestedstate is safe because (1) BlueChip asserts exceptionsimmediately when detecting an inconsistency betweenthe original design and the modified circuit, (2) BlueChipchecks all data-flow pairs for inconsistencies, and (3)BlueChip leverages hardware recovery mechanisms toprevent the persistence of untrusted state modifications.

7 Malicious hardware footholds

This section describes the malicious hardware trojans weused to test the effectiveness of BlueChip. Prior work ondeveloping hardware attacks focused on adding minimaladditional logic gates as a starting point for a system-level attack [22]. We call this type of hardware mecha-nism a foothold. We explored three such footholds. Thefirst foothold, called the supervisor transition foothold,enables an attacker to transition the processor into su-pervisor mode to escalate the privileges of user-modecode. The second foothold, called the memory redi-rection foothold, enables an attacker to read and write

8

arbitrary virtual memory locations. The third foothold,called the shadow mode foothold, enables an attackerto pass control to invisible firmware located within theprocessor and take control of the system. Previous workhas shown how these types of footholds can be usedas part of a system-level attack to carry out high-level,high-value attacks, such as escalating privileges of aprocess or enabling attackers to login to a remote systemautomatically [22].

7.1 Supervisor transition footholdOur supervisor transition foothold provides a hardwaremechanism that allows unprivileged programs to tran-sition the processor into supervisor mode. This transi-tion grants access to privileged instructions and bypassesthe usual hardware-enforced protections, allowing theattacker to escalate the privileges of an otherwise unpriv-ileged process.

The malicious hardware is triggered when it observesa sequence of instructions being executed by the pro-cessor. This attack sequence can be arbitrarily longto avoid false positives, and the particular sequence ishard coded into the hardware. This foothold requiresrelatively few transistors. We implement it by including asmall state machine in the integer unit (i.e., the pipeline)of the processor that looks for the triggering sequenceof instructions, and asserts the supervisor-mode bit whenenabled.

7.2 Memory redirection footholdOur memory redirection foothold provides hardwaresupport for unprivileged malicious software by allowingan attacker to access arbitrary virtual memory locations.

This foothold uses a sequence of bytes as the trig-ger. In this case, when the foothold observes storeinstructions with a particular sequence of byte values itthen interprets the subsequent bytes as the redirectionaddress. The malicious logic records the address of theblock and the redirection address in hardware registers.The next time the address is loaded from memory, themalicious hardware substitutes the redirection address asthe address to be loaded and asserts the supervisor bitpassed to the memory management unit (MMU). Thatis, the next read to this block will return the value ofa different location in the memory. Memory writes arehandled analogously, in that the next write to the blockis redirected to write to the redirection address. The neteffect is providing full access to arbitrary virtual memorylocations and bypassing MMU protections enforced inthe processor.

This foothold provides flexibility for attackers becauseattackers can trigger the circuit using only data values.

Attackers can trigger the foothold by injecting specificdata values into a system using a number of techniquesincluding unsolicited network packets, emails, and im-ages on web sites. By using these mechanisms toarbitrarily manipulate the system’s memory, a remoteattacker can compromise the system, for example, bysearching memory for encryption keys, disabling authen-tication checks by modifying the memory of the targetedsystem, or altering executable code running on the sys-tem.

7.3 Shadow mode foothold

The shadow mode foothold allows an attacker to injectand execute arbitrary code. The shadow mode footholdworks by monitoring data values as they pass betweenthe cache and the pipeline, and installs an invisiblefirmware within the processor when a specific value trig-gers the attack. When this firmware runs, it runs with fullprocessor privileges, it can gain control of the processorat any time, and it remains hidden from software runningon the system. To provide storage for exploit instructionsand data, this foothold reserves blocks in the instructionand data caches for storing injected instructions and data.The shadow mode foothold is triggered with a sequenceof bytes and the shadow mode foothold interprets thebytes following the trigger sequence as commands andmachine instructions.

To evaluate BlueChip, we implement the “bootstraptrigger” portion of the shadow mode foothold. The boot-strap trigger waits for a predetermined value to be storedto the data cache, and asserts a processor exception thattransfers control to a hard-coded “bootstrap code” thatresides within the processor cache. Our implementationincludes the “bootstrap trigger” and asserts a processorexception, but omits the “bootstrap code” portion of thefoothold. As a result, we are unable to implement fullsystem attacks using our version of the foothold, but itdoes give us enough of the functionality of the shadowmode foothold to enable us to evaluate our defensebecause removing the “bootstrap trigger” disables theattack.

8 BlueChip prototypeTo experimentally verify the BlueChip approach, weprototyped the hardware, the software, and the design-time UCI analysis algorithm.

We based our hardware implementation on the Leon3processor [15] design. Our prototype is fully synthesiz-able and runs on an FPGA development board that in-cludes a Virtex 5 FPGA, CompactFlash, Ethernet, USB,VGA, PS/2, and RS-232 ports. The Leon3 processor

9

implements the SPARC v8 instruction set [24] and ourconfiguration uses eight register windows, a 16 KB in-struction cache, a 64 KB data cache, includes an MMU,and runs at 100 MHz, which is the maximum clock ratewe are able to achieve for the unmodified Leon3 design,for our target FPGA. For the software, we use a SPARCport of the Linux 2.6.21.1 kernel on our FPGA board andwe install a full Slackware distribution on our system.By evaluating BlueChip on an FPGA development boardand by using commodity software, we have a realisticenvironment for evaluating our hardware modificationsand accompanying software systems.

To insert our BlueChip hardware modifications, wewrote tools that take as input data-flow pairs generated byour UCI implementation and automatically transformsthe Leon3 VHDL source code to replace suspicious cir-cuits and add exception delivery logic. Our tool is mostlyhardware-implementation agnostic and should work ona wide range of hardware designs automatically. Theonly hardware implementation specific portions of ourtool are for connecting the BlueChip logic to the Leon3exception handling stage.

For our UCI implementation, we wrote a VHDL com-piler front end in Java which generates a data-flow graphfrom arbitrary HDL source code, determines all possiblepairs of edges in the data-flow graph, then uses TCL toautomatically drive ModelSim, running the simulationand removing pairs that are violated during testing. Thelast stage of our UCI implementation performs a source-to-source transformation using the original VHDL de-sign and remaining data-flow pairs to generate a designwith BlueChip hardware.

Our BlueChip software runs as an exception handlerwithin the Linux kernel. The BlueChip emulation code iswritten in C and it can emulate all non-privileged SPARCinstructions and most of the privileged operations of theLeon3 SPARC implementation. Because SPARC is a re-duced instruction set computer (RISC), we implementedour emulator using only 1759 lines of code and it tookus about a week to implement our instruction emulationroutines.

We identify suspicious hardware using three sets oftests: the basic test suite included with the Leon3 distri-bution, SPARC certification test cases from SPARC In-ternational, and five additional test cases to test portionsof the instruction set specification that are uncovered bythe basic Leon3 and SPARC certification test cases. Toidentify suspicious logic, we simulate the HDL usingModelSim version 6.5 and perform the UCI analysis onthe simulation results. Our analysis focuses on the inte-ger unit (i.e., the core pipeline) of the Leon3 processor.

9 BlueChip evaluation

This section describes our evaluation of BlueChip. In ourevaluation, we measure BlueChip’s: (1) ability to stop at-tacks, (2) ability to successfully emulate instructions thatused hardware removed by BlueChip, and (3) hardwareand software overheads.

9.1 Methodology

To evaluate BlueChip’s ability to prevent and recoverfrom attacks, we wrote software that activates the mali-cious hardware described in Section 8. We designed thesoftware to activate and exploit the low-level footholdsimplemented by our attacks, and tested to see if theseout-of-spec abstractions were rendered powerless and ifthe system could make post attack progress.

To identify suspicious circuits, we used three differentsets of hardware design verification tests. First, we usedthe Gaisler test suite that comes bundled with the Leon3hardware’s HDL code. These test cases use ISA-levelinstructions to test both the processor core and peripheral(i.e., outside the processor core) units like the caches,memory management unit, and system-on-chip unitssuch as the UART. Second, we used the official SPARCverification tests from SPARC International, which areused to ensure compatibility with the SPARC instructionset. These test cases are designed to confirm that aprocessor implements the instructions and architecturallyvisible states needed to be considered a SPARC proces-sor, but they are not intended to be a complete designverification suite. Third, we created a small set of customhardware test cases to improve design coverage, closerto what is common in a production environment. Thecustom test cases cover gaps in the Gaisler test casesand exercises instructions that Leon3 supports, but areoptional in the SPARC ISA specification (e.g., floating-point operations).

To measure execution overhead, we used three work-loads that stressed different parts of the system: wgetfetches an HTML document from the Web and representsa network bound workload, make compiles portions ofthe ntpdate application and stresses the interaction be-tween kernel and user modes, and djpeg decompresses a1MB jpeg image as a representative of a compute-boundworkload. To address variability in the measurements,reported execution time results are the average of 100 ex-ecutions of each workload relative to an uninstrumentedbase hardware configuration. All of our overhead exper-iments have a 95% confidence interval of less than 1% ofthe average execution time.

10

Attack Prevent RecoverPrivilege Escalation

√ √

Memory Redirection√

Shadow Mode√ √

Figure 8: BlueChip attack prevention and recovery.

9.2 Does BlueChip prevent the attacks?

There are two goals for BlueChip when aiming to defendagainst malicious hardware. The first and most importantgoal is to prevent attacks from influencing the state ofthe system. The second goal is for the system to recover,allowing non-malicious programs to make progress afteran attempted attack.

The results in Figure 8 show that BlueChip success-fully prevents all three attacks, meeting the primary goalfor success. BlueChip meets the secondary goal of re-covery for two of the three attacks, but it fails to recoverfrom attempted activations of the memory redirectionattack. In this case, the attack is prevented, but softwareemulation is unable to make forward progress. Uponfurther examination, we found that the Leon3’s built-inpipeline recovery mechanism was insufficient to clear theattack’s internal state. This lack of progress is due tothe attack circuit ignoring the Leon3 control signal thatresets registers on pipeline flushes, thus making someattack states persist even after pipeline flushes. This sit-uation causes the BlueChip hardware to repeatedly trapto software, thus blocking forward progress, but prevent-ing the attack. Our analysis indicates that augmentingLeon3’s existing recovery mechanism to provide addi-tional state recovery would allow BlueChip to recoverfrom this attack as well.

9.3 Is software emulation successful?

BlueChip justifies its aggressive identification and re-moval of suspicious circuits by relying on software toemulate any mistakenly removed functionality. Thus,BlueChip will trigger spurious exceptions (i.e., thoseexceptions that result from removal of logic mistakenlyidentified as malicious). In our experiments, all of thebenchmarks execute correctly, indicating BlueChip cor-rectly recovers from the spurious BlueChip exceptionsthat occurred in these workloads.

Figure 9 shows the average rate of BlueChip excep-tions for each benchmark. Even in the worst case, wherea BlueChip exception occurs every 20ms on average, thefrequency is far less than the operating system’s timerinterrupt frequency. The rate of BlueChip exceptionsis low enough to allow for complex software handlerswithout sacrificing performance.

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

wget make jpeg wget make jpeg wget make jpeg

Privilege Escalation MemoryRedirection

Shadow Mode

traps/s

Figure 9: BlueChip software invocation frequencies.

Figure 10 shows the experimental data used to quan-tify the effectiveness of UCI. This figure shows the num-ber of suspicious pairs remaining after each stage of test-ing. The misidentified pairs, which are all false positivesfor our tests, are the number of suspicious pairs minusthe number of attack pairs detected. These false positivepairs can manifest themselves as spurious BlueChip ex-ceptions during runtime. The number of pairs remainingafter testing affects the likelihood of seeing spuriousBlueChip exceptions, with fewer pairs generally leadingto less frequent traps. Even though some of the remain-ing pairs result in spurious exceptions, the instruction-level emulation provided by BlueChip software hidesthis behavior from the rest of the system, thus allowingunmodified applications to execute unaware that they arerunning on BlueChip hardware.

The discrepancy in the number of traps experienced byeach benchmark is also worth noting. The make bench-mark experiences the most traps, by almost an order ofmagnitude. Looking at the UCI pairs that fire duringtesting, and looking at the type of workload make creates,the higher rate of traps comes from interactions betweenuser and kernel modes. This happens more often inmake than the other benchmarks, as make creates a newprocess for each compilation. More in-depth tracing ofthe remaining UCI pairs reveals that many pairs surroundthe interaction between kernel mode and user mode.Because UCI is inherently based on design verificationtests, this perhaps indicates the parts of hardware leasttested in our three test suites. Conversely, the relativelysmall rate of BlueChip exceptions experienced by wgetis due to its I/O (network) bound workload. Most of thetime is spent waiting for packets, which apparently doesnot violate any of the UCI pairs remaining after testing.

11

Baseline Gaisler Tests +SPARC Tests +Custom TestsAttack All Attack All Attack All Attack All

Privilege Escalation 2 3046 1 103 1 87 1 39Memory Redirection 54 3098 8 110 8 94 8 46Shadow Mode 8 3051 1 103 1 87 1 39

Figure 10: UCI dataflow pairs. This figure shows how many dataflow pairs UCI identifies as suspicious for the Gaislertest suite, the SPARC verification test suite, and our custom test cases, cumulatively. The data shows the number ofdataflow pairs identified total, and shows how many of these pairs are from attack circuits.

0

0.2

0.4

0.6

0.8

1

1.2

wget make jpeg wget make jpeg wget make jpeg

PrivilegeEscalation

MemoryRedirection

Shadow Mode

Nor

mal

ized

Ru

nti

me

SoftwareHardwareBase

Figure 11: Application runtime overheads for BlueChipsystems.

9.4 Is BlueChip’s runtime overhead low?

Although BlueChip successfully executes our bench-mark workloads, frequent spurious exceptions have thepotential to significantly impact system performance.Furthermore, BlueChip’s hardware transformation couldimpact the hardware’s operating frequency.

Figure 11 shows the normalized breakdown of runtimeoverhead experienced by the benchmarks running on aBlueChip system versus an unprotected system. Theruntime overhead from the software portion of BlueChipis just 0.3% on average. The software overhead comesfrom handling spurious BlueChip exceptions, primarilyfrom just two of the UCI pairs. The average overheadfrom the hardware portions of BlueChip is approxi-mately 1.4%.

Figure 12 shows the relative cost of BlueChip interms of power, device area, and maximum operatingfrequency. The hardware overhead in terms of areaaverages less than 1% of the entire design. Even thoughBlueChip needs hardware to monitor the remaining pairs,much of the hardware already exists and BlueChip justtaps the pre-existing signals. The majority of the area

Power Area Freq.Attack (W) (Luts) (MHz)Privilege Escalation 0.41% 1.38% 0.00%Memory Redirection 0.47% 1.19% 5.00%Shadow Mode 0.29% 0.31% 0.00%

Figure 12: BlueChip hardware overheads for each of ourattacks.

overhead comes from the comparisons used to determineif a BlueChip exception is required given the state ofthe pipeline. To reduce BlueChip’s impact on maximumfrequency, these comparisons happen in parallel andBlueChip’s exception generation uses a tree of logical-OR operations. In fact, for the privilege escalation andshadow mode versions of BlueChip, there is no mea-surable impact on maximum frequency, indicating thatUCI pair checking hardware is typically off the criticalpath. For the memory redirection attack hardware de-sign, some of the pair checking logic is placed on thememory path, which is the critical path for this designand target device. In this case, the maximum frequencyis reduced by five percent. Consistent with the smallamount of additional hardware, the power overhead av-erages less than 0.5%.

10 Additional related work

In addition to specific work discussed in previous sec-tions, our work is more broadly related to research onattacks and defenses. We are not the first to look atmalicious hardware and defenses. However, prior workhas focused on other aspects of malicious hardware, suchas fabrication-level supply chain attacks, detection ofcounterfeit chips, programmable hardware [17] and iso-lation of circuits within FPGAs. This section describeswork on detecting and isolating malicious hardware, de-tecting source-code-level security flaws, and hardwareextensibility.

12

10.1 Trojan detection & isolation

Agrawal et al. [3] propose signal processing techniquesto detect additional circuits through power side-channelpower analysis. This promising approach faces two keychallenges. First, it assumes that the defender has areference copy of the chip without a trojan circuit, anassumption breaks down if an attacker can modify thedesign of the circuit directly. Second, the results are forpower simulations on small (on the order of 1000 gate)circuits. Although the results are promising, it is unclearhow well these techniques will work in practice and onlarge circuits, such as microprocessors.

Huffmire et al. [19] propose isolation primitives forhardware components designed to run on field pro-grammable gate array (FPGA) hardware. These isolationprimitives can help system builders reason about con-nections between components, but provide little or noprotection against potentially malicious central compo-nents — such as a memory controller or processor —that need to communicate with most or all componentson the system.

Process variations cause each chip to behave slightlydifferently, and such analog side effects can be usedto identify individual chips. Gassend, et al. [16] usethis fact to create physically random functions (PUFs)that can be used to uniquely identify individual chips.Chip identification ensures that chips are not swapped intransit, but provides no detection capabilities for chipsthat include malicious hardware in the design.

10.2 Detecting source code modifications

Formal methods such as symbolic execution [9, 10],model checking [6, 13, 28], and information flow [23, 29]have been applied to software systems for better testcoverage and improved security analysis. These diverseapproaches can be viewed as alternatives to UCI, andmay provide promising extensions for UCI to detect ma-licious hardware if correct abstractions can be developed.

10.3 Hardware extensibility

In some respects, the BlueChip system resembles previ-ous work on hardware extensibility, where designers usevarious forms of software to extend and change the waydeployed hardware works. Some examples of this type ofhardware extensibility include patchable microcode [18],firmware-based TLB control in Itanium processors [2],Transmeta code morphing software [14], and Alpha PALcode [5]. Our design uses some of the same hardwaremechanisms used in these systems, but for coping withmalicious hardware rather than design bugs.

11 ConclusionsBlueChip neutralizes malicious hardware introduced atdesign time by identifying and removing suspicioushardware during the design verification phase, while us-ing software at runtime to emulate hardware instructionsto avoid erroneously removed circuitry.

Experiments indicate that BlueChip is successful atidentifying and preventing attacks while allowing non-malicious executions to make progress. Our maliciouscircuit identification algorithm, UCI, relies on the at-tempts to hide functionality to identify candidate cir-cuits for removal. BlueChip replaces circuits identifiedby UCI with exception logic, which initiates a trap tosoftware. The BlueChip software emulates instructionsto detour around the removed hardware, allowing thesystem to attempt to make forward progress. Measure-ments taken with the attacks inserted show that suchexceptions are infrequent when running a commodityoperating system using traditional applications.

In summary, these results show that addressing themalicious insider problem for hardware design is bothpossible and worthwhile, and that approaches can be costeffective and practical.

AcknowledgmentsThe authors thank David Wagner, Cynthia Sturton, BobColwell, and the anonymous reviewers for commentson this work. We thank Jiri Gaisler for assistance withthe Leon3 processor and Morgan Slain and Chris Larsenfrom SPARC International for the SPARC certificationtest benches.

This research was funded in part by the NationalScience Foundation under grants CCF-0811268, CCF-0810947, CCF-0644197, and CNS-0953014, AFOSRMURI grant FA9550-09-01-0539, ONR under N00014-09-1-0770 and N00014-07-1-0907, donations from In-tel Corporation, and a grant from the Internet ServicesResearch Center (ISRC) of Microsoft Research. Anyopinions, findings and conclusions or recommendationsexpressed in this paper are solely those of the authors.

References[1] Maxtor basics personal storage 3200. http:

//www.seagate.com/www/en-us/support/

downloads/personal_storage/ps3200-sw.

[2] Intel Itanium Processor Firware Specifications. http:

//www.intel.com/design/itanium/firmware.htm,March 2010.

[3] D. Agrawal, S. Baktir, D. Karakoyunlu, P. Rohatgi, andB. Sunar. Trojan detection using IC fingerprinting. In

13

Proceedings of the 2007 IEEE Symposium on Securityand Privacy, May 2007.

[4] Apple Computer Inc. Small Number of Video iPodsShipped With Windows Virus. 2006. http://www.

apple.com/support/windowsvirus/.

[5] P. Bannon and J. Keller. Internal architecture of Alpha21164 microprocessor. compcon, 00:79, 1995.

[6] A. Biere, A. Cimatti, E. Clarke, M. Fujita, and Y. Zhu.Symbolic model checking using SAT procedures insteadof BDDs. In Proc. ACM/IEEE Annual Design AutomationConference, pages 317–320, 1999.

[7] Bob Colwell. Personal communication, March 2009.

[8] BugTraq Mailing List. Irssi 0.8.4 backdoor, May 2002.http://archives.neohapsis.com/archives/

bugtraq/2002-05/0222.html.

[9] C. Cadar, D. Dunbar, and D. R. Engler. Klee: Unas-sisted and automatic generation of high-coverage tests forcomplex systems programs. In Proceedings of the 2008USENIX Symposium on Operating Systems Design andImplementation, December 2008.

[10] C. Cadar, V. Ganesh, P. M. Pawlowski, D. L. Dill, andD. R. Engler. Exe: automatically generating inputs ofdeath. In CCS ’06: Proceedings of the 13th ACM Confer-ence on Computer and Communications Security, pages322–335, New York, NY, USA, 2006. ACM.

[11] CERT. Cert advisory ca-2002-24 trojan horse opensshdistribution. Technical report, CERT CoordinationCenter, 2002. http://www.cert.org/advisories/

CA-2002-24.html.

[12] CERT. Cert advisory ca-2002-28 trojan horse send-mail distribution. Technical report, CERT CoordinationCenter, 2002. http://www.cert.org/advisories/

CA-2002-28.html.

[13] H. Chen, D. Dean, and D. Wagner. Model checkingone million lines of C code. In Proceedings of the 11thAnnual Network and Distributed System Security Sympo-sium (NDSS), pages 171–185, 2004.

[14] J. C. Dehnert, B. K. Grant, J. P. Banning, R. Johnson,T. K. A. Klaiber, and J. Mattson. The transmeta codemorphing software: Using speculation, recovery, andadapative retranslation to address real-life challenges. InProceedings of the 1st IEEE/ACM Symposium of CodeGeneration and Optimization, Mar 2003.

[15] Gaisler Research. Leon3 synthesizable processor.http://www.gaisler.com.

[16] B. Gassend, D. Clarke, M. van Dijk, and S. Devadas.Silicon physical random functions. In Proceedings of the9th ACM Conference on Computer and CommunicationsSecurity, pages 148–160, New York, NY, USA, 2002.ACM Press.

[17] I. Hadzic, S. Udani, and J. M. Smith. FPGA Viruses.In Proceedings of 9th International Workshop on Field-Programmable Logic and Applications, FPL’99, LNCS.Springer, August 1999.

[18] L. C. Heller and M. S. Farrell. Millicode in an IBMzSeries processor. IBM J. Res. Dev., 48(3-4):425–434,2004.

[19] T. Huffmire, B. Brotherton, G. Wang, T. Sherwood,R. Kastner, T. Levin, T. Nguyen, and C. Irvine. Moats anddrawbridges: An isolation primitive for reconfigurablehardware based systems. In Proceedings of the 2007IEEE Symposium on Security and Privacy, pages 281–295, Washington, DC, USA, 2007. IEEE Computer Soci-ety.

[20] P. A. Karger and R. R. Schell. Multics Security Eval-uation: Vulnerability Analysis. Technical Report ESD-TR-74-192, HQ Electronic Systems Division: HanscomAFB, June 1974.

[21] P. A. Karger and R. R. Schell. Thirty Years Later: Lessonsfrom the Multics Security Evaluation. In ACSAC ’02:Proceedings of the 18th Annual Computer Security Appli-cations Conference, page 119. IEEE Computer Society,2002.

[22] S. T. King, J. Tucek, A. Cozzie, C. Grier, W. Jiang,and Y. Zhou. Designing and implementing malicioushardware. In Proceedings of the First USENIX Workshopon Large-Scale Exploits and Emergent Threats (LEET),April 2008.

[23] A. C. Myers and B. Liskov. A Decentralized Model forInformation Flow Control. In Proceedings of the 1997Symposium on Operating Systems Principles, October1997.

[24] SPARC International Inc. SPARC v8 processor.http://www.sparc.org.

[25] B. Sullivan. Digital picture frames infected with virus,January 2008. http://redtape.msnbc.com/2008/

01/digital-picture.html.

[26] K. Thompson. Reflections on trusting trust. Commun.ACM, 27(8):761–763, 1984.

[27] United States Department of Defense. Mission impact offoreign influence on DoD software. September 2007.

[28] J. Yang, P. Twohey, D. Engler, and M. Musuvathi. Usingmodel checking to find serious file system errors. InOSDI’04: Proceedings of the 6th Symposium on Oper-ating Systems Design & Implementation, pages 273–288,Berkeley, CA, USA, 2004. USENIX Association.

[29] S. Zdancewic, L. Zheng, N. Nystrom, and A. C. My-ers. Untrusted hosts and confidentiality: secure programpartitioning. In Proceedings of the 2001 Symposium onOperating Systems Principles, October 2001.

14