Cache Timing Side-Channel Vulnerability Checking withComputation Tree Logic

Shuwen Deng, Wenjie Xiong and Jakub SzeferYale University

New Haven, Connecticut{shuwen.deng,wenjie.xiong,jakub.szefer}@yale.edu

ABSTRACTCaches are one of the key features of modern processors as theyhelp to improve memory access timing through caching recentlyused data. However, due to the timing di�erences between cachehits and misses, numerous timing side-channels have been discov-ered and exploited in the past. In this paper, Computation TreeLogic is used to model execution paths of the processor cache logic,and to derive formulas for paths that can lead to timing side-channelvulnerabilities. In total, 28 types of cache attacks are presented: 20types of which map to attacks previously categorized or discussedin literature, and 8 types are new. Furthermore, to enable practicalvulnerability checking, we present a new approach that limits thedepth of the execution paths that need to be checked by the Com-putation Tree Logic, allowing for use of bounded model checkingfor Computation Tree Logic based cache security veri�cation usingthe new three-step single-cache-block-access model.

CCS CONCEPTS• Security and privacy→ Side-channel analysis and counter-measures; • Theory of computation → Modal and temporallogics; Veri�cation by model checking;

KEYWORDStiming side-channel, caches, Computation Tree LogicACM Reference Format:Shuwen Deng, Wenjie Xiong and Jakub Szefer. 2018. Cache Timing Side-Channel Vulnerability Checking with Computation Tree Logic. In HASP’18: Hardware and Architectural Support for Security and Privacy, June 2,2018, Los Angeles, CA, USA. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3214292.3214294

1 INTRODUCTIONWith conventional processor caches, when a memory access ismade, �rst, the memory address is checked to see if the data is inthe cache, and if data is in the cache, it is called a cache hit, and datais returned from the cache quickly. If data is not in the cache, it is acachemiss, and main memory is accessed to retrieve the data, whichtakes longer amount of time. Because of this timing di�erence, it ispossible to use timing of a program execution to determine if itsmemory accesses are hits or misses. Furthermore, when �ushing orevicting a cache block, the timing of these operations depends onwhether the cache block originally had valid data, which can alsoreveal the state of the cache block. The di�erent timing information

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor pro�t or commercial advantage and that copies bear this notice and the full citationon the �rst page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior speci�c permissionand/or a fee. Request permissions from permissions@acm.org.HASP ’18, June 2, 2018, Los Angeles, CA, USA© 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM.ACM ISBN 978-1-4503-6500-0/18/06. . . $15.00https://doi.org/10.1145/3214292.3214294

can then be used to leak secrets of a victim program, and this hasbeen exploited by the various cache timing side-channel attacks,e.g., [1, 5, 7, 21, 30].

To address the security issues of cache timing side-channel at-tacks, numerous secure processor caches have been designed andanalyzed through simulation and probability analysis in attemptto prove that the proposed caches indeed prevent attacks [12, 13,26, 27, 33–36, 39, 40]. Furthermore, to reason about the di�erentattacks, researchers have classi�ed cache timing side-channels onbasis whether the attacks leverage cache hits or misses and whetherthey are access-based or reuse-based, and whether the attacks lever-age internal or external interference [22, 41]. Especially, [41] madeuse of �nite-state machine to model cache architectures and usedmutual information to calculate potential side-channel leakage ofthe modeled cache architectures. Meanwhile, [22] used probabilis-tic information �ow graph to model interaction between a victimand an attacker program, and used probability of an attack successto evaluate how well di�erent caches can defend against timingside-channel attacks.

In contrast to the existing work, this paper is the �rst work toexplore Computation Tree Logic (CTL) [9, 10] to model executionpaths of the processor cache logic, and to derive formulas for pathswhich indicate that there is a vulnerability to a potential attack.Rather than trying to model or simulate attackers, this work explic-itly enumerates all the possible execution paths that could lead toan attack. CTL formulas are derived for these execution paths, andthese formulas can be used with existing tools to check if a speci�ccache architecture is susceptible to one of the attacks. Especially,behavior of each single cache block can be modeled as a Kripkestructure [23], which is used to describe the �nite-state machine ofthe cache logic. Given the CTL formulas, they can be used to verifyif there is at least one path in the computation tree derived fromthe Kripke structure that matches the formula, and if so, there is apotential vulnerability in the design.

The execution paths in computation tree of a cache could bepotentially in�nite. However, we show that any path correspondingto an attack can be represented as a path with three single-cache-block accesses steps (step 0, step 1, and step 2 in Section 4). Whilethe computation tree is still large, it is now bounded in size and allthe paths can be evaluated within this bounded computation treeto �nd potential vulnerabilities.

Through explicit enumeration of all the possible paths and theiranalysis, we have derived CTL formulas for 28 types of cache at-tacks. Of these attacks, 20 types are in agreement with the existingcache attack categorizations presented in [22, 27, 41] or correspondto known vulnerabilities. However, 8 of the types of attacks arepreviously not detailed in literature. The 28 CTL formulas can be ap-plied to evaluate any cache architecture and can check, in boundedtime, if the cache is vulnerable to an attack.

1.1 ContributionsThis paper aims to help advance the �eld of veri�cation of proces-sor caches, and provides logic formulas that can be used to check

HASP ’18, June 2, 2018, Los Angeles, CA, USA S. Deng et al.

cache implementation against potential cache timing side-channelvulnerabilities. Our contributions are:• First use of CTL to model execution paths of the processorcache logic focusing on side-channel attacks.• Development of a new, three-step single-cache-block-accessmodel for modeling all possible vulnerabilities that can leadto timing side-channel attacks in caches.• Derivation of 28 types of cache side-channel attacks basedon the three-step single-cache-block-access model, including8 types of attacks previously not described in the existingliterature in detail.• Discussion of how to �nd cache timing side-channel vul-nerabilities in real cache implementations by using the CTLformulas and bounded model checking.

2 COMPUTATION TREE LOGIC (CTL)In this paper, we use Computation Tree Logic (CTL) [9, 10] to modelexecution paths of the processor cache logic, and to derive formulasfor paths which can lead to attacks. CTL treats time as discrete andbranching, where at each time step the system is in a de�ned state.It allows one to explore di�erent execution paths that a system maygo through as it executes. The number of the paths depends on the�nite state machine describing the system. The lengths of the pathscan be in�nite, but bounded paths can be checked (c.f. boundedmodel checking [6]).

CTL is one type of temporal logic: temporal logic is the logic thatcontains any system of rules and symbolisms to represent, and rea-son about, propositions quali�ed in terms of time [14]. Propositionssuch as “there exists a path that property p holds starting at sometime step until a step where property q holds” enable describing asystem along with changes in its state over time.

There are also other forms of temporal logics, which includeLinear Temporal Logic (LTL) [31] where at every moment in timethere will only be one possible future that “actually takes place” [24].Interval Temporal Logic (ITL) [2, 3] represents both propositionaland �rst-order logical reasoning about periods of time. It is ableto handle both sequential and parallel composition. ComputationTree Logic* (CTL*) [15] is a superset of Computation Tree Logic(CTL) and Linear Temporal Logic (LTL). There are also temporallogics for Hyperproperties [11], which are able to describe a setof trace properties and moreover can describe security policiessuch as noninterference. For this work, we use CTL as it allows forenumerating various execution paths and checking if there existsat least one path that matches a given formula.

2.1 Describing a System for CTL CheckingA system to be checked using CTL needs to be modeled as a �nite-state machine, which can be described by a Kripke structureM =< N, I ,� ,R > [23]. N is the �nite set of states in the system andI ✓ N is the set of initial states. P is the set of Boolean variables(labels), or some primitive propositions, and � : N ! 2P is themapping function of each state to the set of variables that are truein this state. Finally, R ✓ N ⇥ N is the transition relation betweenstates of the system.

Given the Kripke structure M and an initial state s 2 I , thecomputation tree for the execution of the system can be derivedstarting in that state. The tree represents all the possible executionpaths of the system based on all the possible states of the system,its inputs, and the state transitions.

A path from the root node, s , to a leaf node is called a path� . There are many paths in a tree. If a tree is unbounded, therecould be in�nite number of paths — later we explain how our work

Table 1: Symbols of CTL formula syntax.

Symbol DescriptionT rue logical true valuea an atomic proposition

� , �1, �2 valid CTL formulas¬ negation (unary op.)^ logical AND (binary op.)_ logical OR (binary op.)) logical implication (binary op.), logical bi-implication (if and only if, binary op.)A “for all” operator (along all paths, unary op.)E “exists” operator (along at least one path, unary op.)X “next” operator (unary op.)G “globally” operator (unary op.)F “eventually” operator (unary op.)U “until” operator (binary op.)

aaa

a a a a

a

a a

aa

a

a

aa

a

(M, s)╞ AX a (M, s)╞ AG a(M, s)╞ AF a

aba

b

aa

b

(M, s)╞ A[a U b]

(M, s)╞ EX a (M, s)╞ EG a(M, s)╞ EF a (M, s)╞ E[a U b]

b

For all paths next: Is inevitable:

Exists some paths next: Holds potentially:

For all path invariantly:

Potentially always:

For all paths until:

For some path until:

Figure 1: Example paths in computation trees that are true for thecorresponding CTL formulas.

allows for use of bounded trees. If the tree is bounded, a path �Fwill have �nite number of states, m, and the �nite sequence ofstates s0, s1, ..., sm�1 of �F hold that 80 6 i < m, si * si+1 and(si , si+1) 2 R. Paths are written as �F = s0 * s1 * s2 * ... *sm�1, where si is �F [i], indicating the i +1th state in the path. Here� (�F [i]) 2 2P (0 6 i < m) represents the set of variables that aretrue in state �F [i], and* represents the predecessor to successorrelation between states in a path.

2.2 CTL Formula SyntaxCTL formulas can be described using the below syntax:

� ::= True |a |¬� |�1 ^ �2 |�1 _ �2 |�1 ) �2 |�1 , �2 | (1)AX� |EX� |AF� |EF� |AG� |EG� |A(�1U�2) |E (�1U�2)

Symbols are explained in Table 1. The quanti�ers over paths (Aand E) are always combined with path-speci�c quanti�ers (X , G , FandU ). When evaluating CTL formulas, the unary operators bindstronger than the binary ones. Implication ()) and bi-implication(,) have the least precedence.

2.3 Semantics Over PathsCTL formulas are true when there are certain execution pathsin the computation tree for a system that matches that formula.Di�erent CTL semantics, their names, and examples of paths thatmake such formulas true are shown in Figure 1. For example, ifthe CTL formula (M, s ) |= EF� holds for a bounded computationtree of Kripke structureM , there exists at least one state in one ofthe paths in the tree where � holds, i.e. � “holds potentially” in thecomputation tree.

Cache Timing Side-Channel Vulnerability Checking with Computation Tree Logic HASP ’18, June 2, 2018, Los Angeles, CA, USA

s0

s1

s4

s2

s6

ld issue

{probe}

{hit}

{miss}

{replace}{bypass}

ISA-level Microarchitecture-level

ldreturn

{forceevict}

s3

{return data}

s5la

ten

cy ↔

ca

che

hit

or

mis

s

Figure 2: ISA and Microarchitecture level view of cache operation.

3 CACHES AND SIDE-CHANNEL ATTACKSOperation of a processor cache is realized in the hardware cachecontroller logic, which can be described by a �nite state machine.Each type of a processor cache has a �nite number of states in itsstate machine and is deterministic1. The basic unit of a cache isa cache block. Based on the inputs (memory access requests) thestate of each cache block evolves over time. Changes in the stateof a cache block can be expressed as a path in CTL terminology.In this work, we show that CTL formulas can be used to describeexecution paths which may lead to an attack; if for a particularcache state machine the CTL formula is never true, then the cacheis secure against that type of attack.

3.1 Threat ModelTo reason about cache attacks, we assume there is an attackerand a victim sharing the same cache. Third party interference hasequivalent functionality to some victim’s or attacker’s behaviorand is not considered. The attacker cannot directly access the statemachine of the cache logic, but canmake use of the timing di�erencebetween hits and misses to derive information about cache accessesby the victim – a timing side-channel. The attacker is able to observeits own timing and the timing of the operations of the victim. Theattacker knows at least some of the source code of the victim (e.g.it can interpret some information from knowing a speci�c cacheblock access by a victim). The attacker is also able to force victimto execute a speci�c function (e.g. attacker can request victim todecrypt a speci�c piece of data).

3.2 Cache State MachineA cache hit or miss has a one-to-one mapping to the state in theprocessor cache controller logic, and a hit or a miss has directrelation to the timing. Figure 2 shows the operation of a cache attwo abstraction levels.

At the ISA level, memory access instructions, such as ld (load)and st (store), are used to access data. When the instruction isissued, data is requested from the memory subsystem. The cacheblock corresponding to the memory address is accessed. When theinstruction is returned, the data is provided to the processor – for amemory access operation, the latency of the instruction has directrelation to whether it was a cache hit or cache miss. Similarly, fora �ush or evict instruction, the latency of the operation re�ectswhether this cache block was an empty cache block (quick becausethere is nothing to �ush or evict) or was not empty (slow becausethere was data to be �ushed or evicted).

At the microarchitecture level, the cache controller is realized asa Kripke structure describing the �nite state machine of the cachelogic. A simpli�ed structure is shown in Figure 2; a single memory1Certain secure caches use randomization to map addresses to cache blocks, but overallthe operation of the cache is still deterministic.

access at the ISA level, corresponds to a set of state transitions atthe microarchitecture level. The �rst state is s0. Proposition “probe”holds in this state and is used to �nd out if the required data is inthe cache or not. If it is, then s1 state (“hit”) is entered, followed bys4 state (“return data”). If the data is not in the cache, then s2 state(“miss”) is entered, followed by s3 state (“replace”) where someother data is evicted and the requested data is brought into thecache. Finally, s4 state (“return data”) is entered and state will goback to s0 (“probe”) to wait for the next request.

Certain secure caches have other states, such as s5 (“force evict”)or s6 (”bypass”), as shown in the state transition diagram in Figure 2.Other di�erent possibie states exist as well. The goal of these extrastates is to disrupt the timing of a cache hit andmiss, thus eliminatethe one-to-one correspondence between the timing and whetherhit or miss state was entered.

3.3 Timing Side-Channel AttacksBecause of the time di�erences between hits and misses, conven-tional processor caches are susceptible to timing side-channel at-tacks, detailed in surveys such as [16, 28, 32, 42]. In a timing side-channel attack, there are an attacker,A and a victim,V . The goal forthe attacker is to observe the timing of single cache block accessesof the victim or itself, and combined with some other knowledge,to determine what sensitive data the victim is operating on, e.g.,guess bits of a secret key.

The attacker can themselves access a cache block by makingsingle cache block accesses, or trigger the victim to make singlecache block accesses, e.g. request victim to do some known compu-tation, or both. The attacker usually knows what code the victimis executing, e.g. type of encryption algorithm, but does not knowthe victim’s speci�c secrets. For instance, in the Prime + Probeattack [29], by priming to know some initial state of the cache, thenletting victim execute, and �nally observing the time of its ownaccessing to the same cache block, the attacker may extract somesecret information.

4 VULNERABILITY MODELINGThis paper proposes a new approach to reasoning about cache tim-ing side-channel attacks bymodeling execution paths that representvulnerabilities to attacks as CTL formula in the form of:

(M, s ) |= EF (E (E (step 0 U step 1) U step 2))

The vulnerability checking can be done by applying such CTLformulas to a computation tree derived from a state machine of thecache controller, which will be discussed in Section 5.

In this section, we �rst introduce the three-step single-cache-block-access model and discuss the possibilities for each step inSection 4.1. Once all possibilities for each of the steps are described,then in Section 4.2, speci�c vulnerabilities and their CTL formulasfor the three steps are derived. In Section 4.3, we show why thethree-step model can model all possible n-step attacks.

4.1 Three-Step Single-Cache-Block-AccessModel

For a vulnerability to exist, there needs to be an interference be-tween the attacker’s access and the victim’s access to the samecache block, or an interference between two accesses of the vic-tim to the same cache block. To be able to capture this, one needsto analyze di�erent possible accesses to a single cache block, de-noted as “single-cache-block accesses”. Furthermore, at least threesuch accesses, or “steps”, are needed to model the cache timingside-channel attacks.

HASP ’18, June 2, 2018, Los Angeles, CA, USA S. Deng et al.

Table 2: Six possible conditions for state of a single cache block inthe three-step single-cache-block-access modeling procedure.

Condition Description

V1/A1A speci�c memory location of the victim or attacker isbrought into the single cache block targeted by and knownto attacker.

Vx

A piece of memory containing data from a range of vic-tim’s memory addresses is accessed. Attacker knows therange, but not speci�c addresses accessed. Therefore, thetargeted cache block is potentially accessed by Vx .

VR /AR

Victim or attacker does single-cache-block access to “re-move” the cache block contents so neither attacker’sknown data nor victim’s data is in the cache. It can beachieved by using other cache block accessing to evict theoriginal data, or using �ush instructions like cf lush, orcan be achieved using cache coherence protocol.

?Attacker has no knowledge about memory location inthis cache block.

First, some memory operation is performed that sets one singlecache block in some known initial state, which is step 0. Then someaction can be done by the victim or attacker, which is step 1, and�nal action is taken to derive information by observing timing,which is step 2. The attacker should be able to interpret the victim’sbehavior in step 2, if there is a possible attack.

We identify six possible conditions of a cache block in Table 2.V1 requires attacker to drive the victim to access speci�c memorylocation known by the attacker and put it into the cache block,while A1 means the attacker directly accessing a speci�c memoryaddress themselves and putting data at that location. In both casesattacker knows speci�c address of memory location in the cacheblock. Vx is more general than V1, where victim accesses one ofmultiple security critical memory addresses (e.g. one of AES S-Boxtable entries) and put the data into the cache block, but whichspeci�c memory address or which cache block was accessed is notknown. Therefore, potentially the cache block targeted on couldbe accessed by Vx . VR or AR requires attacker or victim to remove(clear or evict) data from a cache block so neither attacker’s knowndata nor victim’s data is in the cache. It can be achieved by usingother cache block accesses to evict the original cache block, or byusing �ush instructions like c f lush, or by using cache coherenceprotocol among di�erent cache levels or even di�erent CPU cores.?means the initial contents of the cache block is unknown to attacker.

4.1.1 Modeling Step 0. The initial state of a cache block canbe modeled as step 0. Any of the six conditions in Table 2 canbe achieved by performing one valid single-cache-block accessoperation by the attacker or victim.

4.1.2 Modeling Step 1. Once the cache block is in a known state,for an attack to exist, some interference needs to be created. Thisis modeled by step 1. There are �ve possible conditions in thisstep: AR , VR , A1, V1 or Vx . ? is excluded as it cannot lead to anattack – putting the cache block in an unknown state removesuseful information.

4.1.3 Modeling Step 2. The �nal step in any attack is to makea cache block access to try to observe whether any interferencehappened. Here possible conditions are AR , VR , A1, V1 or Vx as theattacker needs to e�ectively access a memory location to observe itsown fast / slow timing, resulting from whether it is an empty cacheblock when trying to remove data (for data removal) or whetherit is a cache hit / miss (for data access), or the victim is driven todo some cache block access to put corresponding data or removedata from cache block so attacker can observe victim’s fast / slow

timing. If the observed timing of Step 2 for one single cache blockis always fast or always slow, attacker cannot extract informationfrom (the lack of) timing change. Therefore, timing change is arequirement for e�ective attack, but it is not su�cient.?would notgive useful information and is not considered for this step.

4.1.4 Deriving CTL Formula From the Three Steps. Based on thethree steps, CTL formula are derived in the form of: (M, s ) |=EF (E (E (step 0 U step 1) U step 2)). The possible states for thesteps are inserted in the place of “step 0”, “step 1”, and “step 2”. Forexample, if the states in the conditions are A1, Vx , and A1, then theresulting formula is: (M, s ) |= EF (E (E (A1 U Vx ) U A1)).

4.2 Formulas for AttacksTable 3 shows exhaustive list of all possible three-step combinationsof conditions for one single cache block. As discussed in the priorSection, step 0 can be ?, AR , VR , A1, V1 and Vx , step 1 and step 2can beAR ,VR ,A1,V1 andVx . Based on these, all possible three-stepCTL formulas can be obtained. In Table 3, the three step columnsgive the conditions for each evaluated path. Observed Timing ofstep 2 column represents possible fast or slow timing information.When loading data in step 2, fast load time corresponds to cachehit and slow load time corresponds to cache miss. For a cache blockdata removal (AR or VR ), fast data removal time indicates that thecorresponding cache block previously did not have data and slowdata removal time indicates that the corresponding cache blockpreviously had data. Possible Attack column indicates if the threesteps in the corresponding row represent vulnerability to an attack.Categorization column gives a name to the attack if such existsin a row. Finally, footnote explanations give some intuition why,or why not, the three steps in a table row correspond, or do notcorrespond, to an attack.

Through evaluation of these exhaustive combinations, we havefound in total 28 kinds of vulnerabilities. Of the 28 types of attackspresented in this paper, 20 of them have example attacks, as shownin Table 4. However, the existing example attacks do not coverall possible attacks in some types. For instance, Type M vulnera-bility can be implemented as Flush + Flush attack [18]. But otherremain-to-be-discovered attacks are also possible, e.g., Flush + Evictattack, Evict + Evict attack, etc. Moreover, 8 of the attacks are new.Combined by some common features, these 8 new vulnerabilitiesare explained below.

4.2.1 Type A, B A�acks. For Type A, B attacks, the victim failsto reuse its own security critical memory location in Step 2 becausethere is intermediate access that removes the data from the cacheblock. This implies the contention between di�erent, known mem-ory locations from which data is removed and unknown victim’smemory location for the same cache block.• Victim: performsmemory access to put some security criticalmemory location into the cache block.• Attacker: removes the cache block’s data (Type A) or lets thevictim remove the cache block’s data (Type B).• Victim: performs memory access to put some security crit-ical memory location into the cache block again and theattacker can observe the victim’s data load time. (Longertime indicates this removed cache block’s memory locationof the attacker has the same index as the unknown memorylocation of the victim.)

4.2.2 Type C, D, E, F A�acks. In the Type C, D, E, F attacks,victim experiences cache hit due to attacker’s previous cache blockaccess in step 1, which leads to decreased cache access time. Thistime di�erence is observed by the attacker.

Cache Timing Side-Channel Vulnerability Checking with Computation Tree Logic HASP ’18, June 2, 2018, Los Angeles, CA, USATable

3:Exhaustivelistofallpotentialthree-step

single-cache-blockaccesses

forcache

timing

side-channelvulnerabilityanalysis.

Num

.Step

0Step

1Step

2Observed

Timing

ofStep

2PossibleAttack

Catego-rization

Num

.Step

0Step

1Step

2Observed

Timing

ofStep

2PossibleAttack

Catego-rization

Num

.Step

0Step

1Step

2Observed

Timing

ofStep

2PossibleAttack

Catego-rization

1?

AR

AR

fastN

1—

51VR

VR

V1

slowN

2—

101V1

V1

VR

slowN

3—

2AR

AR

AR

fastN

1—

52A1

VR

V1

slowN

2—

102Vx

V1

VR

slowN

3—

3VR

AR

AR

fastN

1—

53V1

VR

V1

slowN

2—

103?

V1

A1

fastN

4—

4A1

AR

AR

fastN

1—

54Vx

VR

V1

slowN

2—

104AR

V1

A1

fastN

4—

5V1

AR

AR

fastN

1—

55?

VR

Vx

fast/slowN

5—

105VR

V1

A1

fastN

4—

6Vx

AR

AR

fastN

1—

56AR

VR

Vx

fast/slowN

5—

106A1

V1

A1

fastN

4—

7?

AR

VR

fastN

1—

57VR

VR

Vx

fast/slowN

5—

107V1

V1

A1

fastN

4—

8AR

AR

VR

fastN

1—

58A1

VR

Vx

fast/slowN

5—

108Vx

V1

A1

fastN

4—

9VR

AR

VR

fastN

1—

59V1

VR

Vx

fast/slowN

5—

109?

V1

V1

fastN

4—

10A1

AR

VR

fastN

1—

60Vx

VR

Vx

fast/slowY

7Type

B110

AR

V1

V1

fastN

4—

11V1

AR

VR

fastN

1—

61?

A1

AR

slowN

3—

111VR

V1

V1

fastN

4—

12Vx

AR

VR

fastN

1—

62AR

A1

AR

slowN

3—

112A1

V1

V1

fastN

4—

13?

AR

A1

slowN

2—

63VR

A1

AR

slowN

3—

113V1

V1

V1

fastN

4—

14AR

AR

A1

slowN

2—

64A1

A1

AR

slowN

3—

114Vx

V1

V1

fastN

4—

15VR

AR

A1

slowN

2—

65V1

A1

AR

slowN

3—

115?

V1

Vx

fast/slowN

5—

16A1

AR

A1

slowN

2—

66Vx

A1

AR

slowN

3—

116AR

V1

Vx

fast/slowY

6Type

H17

V1

AR

A1

slowN

2—

67?

A1

VR

slowN

3—

117VR

V1

Vx

fast/slowY

6Type

I18

Vx

AR

A1

slowN

2—

68AR

A1

VR

slowN

3—

118A1

V1

Vx

fast/slowY

6Type

J19

?AR

V1

slowN

2—

69VR

A1

VR

slowN

3—

119V1

V1

Vx

fast/slowY

6Type

K20

AR

AR

V1

slowN

2—

70A1

A1

VR

slowN

3—

120Vx

V1

Vx

fast/slowY

7Type

L21

VR

AR

V1

slowN

2—

71V1

A1

VR

slowN

3—

121?

Vx

AR

fast/slowN

5—

22A1

AR

V1

slowN

2—

72Vx

A1

VR

slowN

3—

122AR

Vx

AR

fast/slowY

7Type

M23

V1

AR

V1

slowN

2—

73?

A1

A1

fastN

4—

123VR

Vx

AR

fast/slowY

7Type

N24

Vx

AR

V1

slowN

2—

74AR

A1

A1

fastN

4—

124A1

Vx

AR

slowN

8—

25?

AR

Vx

fast/slowN

5—

75VR

A1

A1

fastN

4—

125V1

Vx

AR

slowN

8—

26AR

AR

Vx

fast/slowN

5—

76A1

A1

A1

fastN

4—

126Vx

Vx

AR

fast/slowY

7Type

O27

VR

AR

Vx

fast/slowN

5—

77V1

A1

A1

fastN

4—

127?

Vx

VR

fast/slowN

5—

28A1

AR

Vx

fast/slowN

5—

78Vx

A1

A1

fastN

4—

128AR

Vx

VR

fast/slowY

7Type

P29

V1

AR

Vx

fast/slowN

5—

79?

A1

V1

fastN

4—

129VR

Vx

VR

fast/slowY

7Type

Q30

Vx

AR

Vx

fast/slowY

7Type

A80

AR

A1

V1

fastN

4—

130A1

Vx

VR

slowN

8—

31?

VR

AR

fastN

1—

81VR

A1

V1

fastN

4—

131V1

Vx

VR

slowN

8—

32AR

VR

AR

fastN

1—

82A1

A1

V1

fastN

4—

132Vx

Vx

VR

fast/slowY

7Type

R33

VR

VR

AR

fastN

1—

83V1

A1

V1

fastN

4—

133?

Vx

A1

fast/slowN

5—

34A1

VR

AR

fastN

1—

84Vx

A1

V1

fastN

4—

134AR

Vx

A1

fast/slowY

6Type

S35

V1

VR

AR

fastN

1—

85?

A1

Vx

fast/slowN

5—

135VR

Vx

A1

fast/slowY

6Type

T36

Vx

VR

AR

fastN

1—

86AR

A1

Vx

fast/slowY

6Type

C136

A1

Vx

A1

fast/slowY

7Type

U37

?VR

VR

fastN

1—

87VR

A1

Vx

fast/slowY

6Type

D137

V1

Vx

A1

fast/slowY

7Type

V38

AR

VR

VR

fastN

1—

88A1

A1

Vx

fast/slowY

6Type

E138

Vx

Vx

A1

fast/slowY

6Type

W39

VR

VR

VR

fastN

1—

89V1

A1

Vx

fast/slowY

6Type

F139

?Vx

V1

fast/slowN

5—

40A1

VR

VR

fastN

1—

90Vx

A1

Vx

fast/slowY

7Type

G140

AR

Vx

V1

fast/slowY

6Type

X41

V1

VR

VR

fastN

1—

91?

V1

AR

slowN

3—

141VR

Vx

V1

fast/slowY

6Type

Y42

Vx

VR

VR

fastN

1—

92AR

V1

AR

slowN

3—

142A1

Vx

V1

fast/slowY

7Type

Z43

?VR

A1

slowN

2—

93VR

V1

AR

slowN

3—

143V1

Vx

V1

fast/slowY

7Type

AA

44AR

VR

A1

slowN

2—

94A1

V1

AR

slowN

3—

144Vx

Vx

V1

fast/slowY

6Type

AB

45VR

VR

A1

slowN

2—

95V1

V1

AR

slowN

3—

145?

Vx

Vx

fastN

4—

46A1

VR

A1

slowN

2—

96Vx

V1

AR

slowN

3—

146AR

Vx

Vx

fastN

4—

47V1

VR

A1

slowN

2—

97?

V1

VR

slowN

3—

147VR

Vx

Vx

fastN

4—

48Vx

VR

A1

slowN

2—

98AR

V1

VR

slowN

3—

148A1

Vx

Vx

fastN

4—

49?

VR

V1

slowN

2—

99VR

V1

VR

slowN

3—

149V1

Vx

Vx

fastN

4—

50AR

VR

V1

slowN

2—

100A1

V1

VR

slowN

3—

150Vx

Vx

Vx

fastN

4—

1Observed

timing

ofstep2’sdata

removalw

illalwaysbe

fast,becausedata

inthiscache

blockisalready

removed

inStep

1.2Observed

timing

ofstep2’sdata

accessingwillalw

aysbeslow

,becausedata

inthiscache

blockisrem

ovedinStep

1.3Observed

timing

ofstep2’sdata

removalw

illalwaysbe

slow,because

datain

thiscacheblock

isaccessedinStep

1.4Observed

timing

ofstep2’sdata

accessingwillalw

aysbefast,because

datain

thiscacheblock

isalreadyaccessed

inStep

1.5Victim

’sbehaviorfromtim

ingobservation

cannotbeinterpreted

becausethere

aredi�erentpossibilitiesexisting

fordi�erentsubsetsofStep0.

6Observed

timing

ofStep2dependson

whethervictim

’sunknownaddressin

Step1orStep

2mapsto

thesam

ecache

blockas

attacker’sknow

naddress.Fasttim

ingmeans

thesam

ecache

blockismapped,w

hileslow

timing

means

theopposite

situation.7Observed

timing

ofStep2depends

onwhethervictim

’sunknow

naddress

inStep

1orStep

2have

thesam

eindex

inthe

cacheas

attacker’sorvictim

’sknow

naddress.Slow

timing

means

theyhave

thesam

eindex,w

hilefasttim

ingmeans

theopposite

situation.8Observed

timing

ofstep2’s

datarem

ovalwillalw

aysbe

slow,because

datain

thiscache

blockisaccessed

inStep

0no

matterw

hatstep

1’sVxaddressis.

HASP ’18, June 2, 2018, Los Angeles, CA, USA S. Deng et al.

Table 4: Di�erent types of cache timing side-channel attack vulner-abilities extracted from all possible combinations listed in Table 3and their relations with existing attack categorizations or knownattack examples.

CTL Format of the AttackCategori-zation in

thispaper

Categori-zation in[22][27]

Categori-zationin [41]

KnownAttackExample

EF (E (E (Vx U AR ) U Vx )) Type A — —EF (E (E (Vx U VR ) U Vx )) Type B — —EF (E (E (AR U A1 ) U Vx )) Type C — —EF (E (E (VR U A1 ) U Vx )) Type D — —EF (E (E (A1 U A1 ) U Vx )) Type E — —EF (E (E (V1 U A1 ) U Vx )) Type F — —EF (E (E (Vx U A1 ) U Vx )) Type G Type 1 — (1)EF (E (E (AR U V1 ) U Vx )) Type H Type 3 Type IV (2)EF (E (E (VR U V1 ) U Vx )) Type I Type 3 Type IV (2)EF (E (E (A1 U V1 ) U Vx )) Type J Type 3 Type IV (2)EF (E (E (V1 U V1 ) U Vx )) Type K Type 3 Type IV (2)EF (E (E (Vx U V1 ) U Vx )) Type L — Type II (3)EF (E (E (AR U Vx ) U AR )) Type M — — (4)EF (E (E (VR U Vx ) U AR )) Type N — — (4)EF (E (E (Vx U Vx ) U AR )) Type O — — (4)EF (E (E (AR U Vx ) U VR )) Type P — — (4)EF (E (E (VR U Vx ) U VR )) Type Q — — (4)EF (E (E (Vx U Vx ) U VR )) Type R — — (4)EF (E (E (AR U Vx ) U A1 )) Type S Type 4 Type III (5)EF (E (E (VR U Vx ) U A1 )) Type T Type 4 Type III (5)EF (E (E (A1 U Vx ) U A1 )) Type U Type 2 Type I (6)EF (E (E (V1 U Vx ) U A1 )) Type V — —EF (E (E (Vx U Vx ) U A1 )) Type W Type 4 Type III (5)EF (E (E (AR U Vx ) U V1 )) Type X Type 3 Type IV (2)EF (E (E (VR U Vx ) U V1 )) Type Y Type 3 Type IV (2)EF (E (E (A1 U Vx ) U V1 )) Type Z — —EF (E (E (V1 U Vx ) U V1 )) Type AA — Type II (3)EF (E (E (Vx U Vx ) U V1 )) Type AB Type 3 Type IV (2)(1) Evict + Time attack [29]. (4) Flush + Flush attack [18].(2) Cache Collosion attack [7]. (5) Flush + Reload attack [37, 38], Evict + Reload attack [19].(3) Bernstein’s attack [5]. (6) Prime + Probe attack [29, 30], Alias-driven attack [20].

• Attacker: removes the cache block’s data (Type C) or lets thevictim remove the cache block’s data (Type D) or accesses acache block at a known memory location (Type E) or drivesthe victim to access a cache block at knownmemory location(Type F).• Attacker: accesses the cache block with known memorylocation again.• Victim: performsmemory access to put some security criticalmemory location into the cache block and the attacker canobserve the victim’s data load time. (Shorter data accesstime indicates victim’s address of security critical memorylocation maps to the same cache block as attacker’s knownmemory location.)

4.2.3 Type V A�ack. In this attack, there is contention betweenknownmemory address of the victim and unknown victim’s addressfor the same cache block:• Victim: performs memory access to put corresponding mem-ory location known to the attacker into the cache block.• Victim: performsmemory access to put some security criticalmemory location into the cache block.• Attacker: accesses the same memory location as victim’sknown address, observes if there is a hit or a miss due tocontention with victim’s prior accesses. (A miss indicatesattacker’s memory location has the same index as unknownvictim’s security critical memory access.)

4.2.4 Type Z A�ack. In the Type Z attack, the victim fails toreuse attacker’s same known initial memory location because ofthe intermediate unknown victim’s memory access. This impliesthe contention between di�erent known memory location andunknown victim’s memory location for the same cache block.

• Attacker: performs memory access to put correspondingmemory location known to itself into the cache block.• Victim: performsmemory access to put some security criticalmemory location into the cache block.• Victim: accesses the cache block at the same location asthe attacker; attacker observes the timing to derive victim’shit or miss information. (Longer time indicates this knownvictim’smemory location has the same index as the unknownmemory location of the victim.)

4.3 Analysis of Three-StepSingle-Cache-Block-Access Model

In the following discussion, we will analyze why three-step single-cache-block-access model can cover all possible cache timing side-channel vulnerabilities based on our threat model, while less-than-three-step model is inadequate, and why using more steps is notnecessary. Let � denotes the number of single-cache-block accessesin one attack, � denotes the number of single-cache-block accessesin a model to model all possible attacks. �, � , n 2 Z+.

We �rst show the model needs at least three accesses to modelall possible attacks (� > 2) by proof of contradiction. If � 6 2, themodel with � accesses cannot model Type A vulnerability, whichis required to have three single-cache-block accesses by victim,attacker and victim, respectively. This contradicts the assumptionthat a model with � accesses can model all attacks. Therefore, � > 2.

We want to show the model with � = 3 accesses can model allpossible attacks with any � accesses. (i) For � = 1, interferencebetween attacker’s and victim’s access to a cache block, or betweentwo accesses of the victim is not possible, thus no attack can beachieved by one access. (ii) For � = 2, we can use the three-stepmodel by setting Step 0 to be?– this �rst single-cache-block accessgives no information and thus the next two steps form a two-stepsingle-cache-block accesses. As shown in the exhaustive lists ofTable 3, there is no attacks with Step 0 being ?. (iii) For � = � = 3,the model has the same number of steps as the attack. Table 3gives exhaustive list of all possible three-step single-cache-blockaccesses and shows that there are 28 types of attacks, thus � canbe 3 and � = 3 can cover this condition. (iv) For � > 3, let �⇤denote the number of accesses in a cache access sequence that hasthe property: If the sequence of � access can form an attack, thesequence of �⇤ access must also be an attack. The sequence of �-step single-cache-block accesses can be reduced to �⇤-step accessesbased on following rules:

(1) If single cache block accesses have a sub-pattern such as {... ? ...}, they can be divided into two separate parts,based on the position of?. The original �⇤-step single-cache-block-access model can then be reduced by at least 1 stepfor each of the two separate patterns. Each pattern can berecursively analyzed again.

(2) If the remaining single cache block accesses have a patternsuch as {... AR AR ...}, {... AR VR ...},{... VR AR ...}, {... VR VR ...}, {... A1 A1 ...}, {... A1 V1 ...}, {... V1 A1 ...}, {... V1 V1 ...}, {... Vx Vx ...},due to the repeat single cache block location accessed, theycan be reduced to {... AR ...}, {... VR ...},{... AR ...}, {... VR ...}, {... A1 ...},{... V1 ...}, {... A1 ...}, {... V1 ...},{... Vx ...}, respectively. Therefore, �⇤ can be reducedto (�⇤ � 1). Each pattern can be recursively analyzed again.

(3) Following the above two rules, either �⇤ 6 3 holds, or the fol-lowing sub-patterns in the single-cache-block access pattern

Cache Timing Side-Channel Vulnerability Checking with Computation Tree Logic HASP ’18, June 2, 2018, Los Angeles, CA, USA

still exist: {... (AR/VR/A1/V1) Vx (AR/VR/A1/V1) ...} or {... Vx (AR/VR/A1/V1) Vx ...}. Thesetwo patterns map to known vulnerabilities listed in Table 4:Type M, N, P, Q, S, T, U, V, X, Y, Z, AA for the �rst sub-pattern(Except 4 combinations derived from {... (A1/V1) Vx (AR/VR ) ...} where slow data removal time is cer-tain because of Step 0’s known data accessing and timingobservation of AR/VR is always slow), and Type A, B, G andL for the second sub-pattern. Therefore, the longer patternof multiple cache block accesses will always be matched bythese known three-step vulnerability patterns: �⇤ can bealways reduced to less than or equal to three steps, whichcan be covered by �-step modeling where � equals to 3.

In conclusion, � = 3, which shows three-step single-cache-block-access model can cover all possible timing cache side-channel vul-nerabilities based on our threat model and is the most simpli�edmodel. At the same time, modeling paths having more than threesteps can be reduced to three steps only.

5 VULNERABILITY CHECKINGGiven the CTL formulas for potential vulnerabilities, they need to beapplied to a cache for actual veri�cation of the given cache design.The complexity of the checking depends on the cache architecture.Core ideas of the vulnerability checking in this Section are:• Modeling state transitions of each cache block as a compu-tation tree derived from the Kripke structure based on thecache controller logic.• Bounding number of states of the execution paths in thecomputation tree according to the three-step model.• Mapping each step of three-step single-cache-block-accessmodel to the states in the computation tree and checkwhetherthe CTL formulas for each attack in Table 4 hold or not.

5.1 Bounded Checking with Three-StepSingle-Cache-Block-Access Rule

Figure 3 shows a simpli�ed cache state machine (described as aKripke structure) targeting on only one single cache block andusing “ld” instruction accessing as the example. It follows Figure 2,but with s5 (“force evict”) and s6 (”bypass”) states omitted. Foreach element of the Kripke structure M = < N, I ,� ,R >, N ={s0, s1, s2, s3, s4}, I = s0, � = {s0 ! {probe}, s1 ! {hit}, s2 !{miss}, s3 ! {replace}, s4 ! {return data}}, R = {s0 * s1, s0 *s2, s1 * s4, s2 * s3, s3 * s4, s4 * s0}. The cache starts in s0state (“probe”) – consequently the computation tree is rooted at thes0 state. From there, for all possible addresses of data in the cacheblock (for the Figure example addresses are 1 bit, so there are 2possible values) and for all the possible memory requests (again,two possibilities for the address in Figure 3), a computation tree isbuilt by enumerating all the possible transitions. The computationtree for the example is shown on the right-hand side of Figure 3.

From the s0 state (“probe”) the tree is built, and di�erent statesare explored in the execution paths. Eventually, each path will reachthe s4 state (“return data”). This is equivalent to having �nished onesingle-cache-block-access operation. For our proposed modeling,total of three operations are needed, thus each path is exploredfurther. From s4 state (“return data”) the s0 state (“probe”) is visited,and again all the possible paths inputs are considered. Note, thistime the data in the cache block is �xed (it is the data in the blockat the prior s4 state (“return data”)) so only di�erent cache inputsare considered but not di�erent states of that block. Going forward,each path will have s4 state (“return data”) again (end of secondsingle-cache-block access). The tree is further expanded until third

s0

s1

s4

s2

{probe}

{miss}

{replace}

s3

{returndata}

{hit}

Unfold from s0 to

computation tree

(s0,0)

(s1,1) (s

2,1)

(s3,2)(s

4,2)

(s0,3) (s

4,3)

(s0,4)(s

1,4) (s

2,4)

(s3,5)(s

4,5)

(s0,6) (s

4,6)

(s0,7)(s

1,7) (s

2,7)

(s1,5) (s

2,5)

(s3,6)(s

4,6)

(s0,7) (s

4,7)

(s1,8) (s

2,8)(s

3,8)(s

4,8)

(s4,9)

(s1,8) (s

2,8)

(s1,8) (s

2,8)(s

3,9)(s

4,9)

(s4,10)

(s0,7)

(s3,9)(s

4,9)

(s4,10) (s

3,10)(s

4,10)

(s4,11)

Step 0

Step 1

Step 2

Figure 3: Simpli�ed sample cache controller Kripke structure, fol-lowing Figure 2, butwith the s5 state (force evict) and s6 state (bypass)omitted; and the resulting computation tree of three-step single-cache-block-access model. For convenience, each node in the treeis composed of a pair indicating the state in the Kripke structureand the level of the node in the tree.s4 state (“return data”) is reached on each path. Di�erent caches,especially secure caches, may have many di�erent intermediatestates so the tree can become quite complicated, but will havesimilar structure and each path will be bounded.

Based on the discussion of Section 4, known cache side-channelvulnerabilities can be represented by the three-step model. Thus,checking states of three single-cache-block accesses is enough toverify di�erent possibilities of cache timing side-channel vulnera-bilities for di�erent caches.

5.2 Secure Cache Model Checking with CTLIn order to prevent di�erent types of cache timing side-channelvulnerabilities listed in Table 4, the designs of secure caches shouldnot allow paths which correspond to the vulnerability to exist in thestate transition of cache’s computation tree unfolded from cache’sKripke structure.

When a secure cache is implemented and a computation treesimilarly as right-hand side of Figure 3 is derived from the corre-sponding Kripke structure, in order to check formula derived fromSection 4 with each step under the condition from Table 2, primitivepropositions (2P ) for each state should have: address of the data inthe cache block, whom the addresses belong to (victim or attacker)and condition of that block (“probe”, “hit”, “miss”, “�ushing”, etc.).Other primitive propositions should be removed using predicateabstraction [17] to simplify the state machine. With the above in-formation for each state, a mapping function from the primitivepropositions to conditions described in Table 2 can be derived andwhich condition one state corresponds to can be obtained. Eachof the 28 types of cache timing side-channel vulnerabilities in theform of CTL formula will then be checked one by one based onthe mapping function to see if the represented vulnerabilities existin the computation tree for each single cache block of the securecache designs.

5.3 Towards Veri�cation of Secure CachesAs the number of states in each path of the tree is �nite, it is possibleto use Bounded Modeling Checking (BMC) [6] for the vulnerabil-ity checking. There are existing tools that allow for performingbounded modeling checking for CTL logic. UPPAAL [25] is an in-tegrated tool environment to model, simulate and verify real-timeembedded systems. RuleBase [4] is an industry-oriented formalveri�cation tool to formally verify critical portions of hardware

HASP ’18, June 2, 2018, Los Angeles, CA, USA S. Deng et al.

designs. NuSMV 2 [8] takes SMV modeling language with CTLspeci�cations to do model checking.

Our ongoing work is on implementation of various secure cachedesigns and using the tools listed above to check for existence ofpotential vulnerabilities in the di�erent cache designs. We expectthe three-step bounded single-cache-block-access model will allowfor fast, practical veri�cation of cache architectures.

6 CONCLUSIONCache timing side-channel vulnerabilities based on cache accessand timing di�erences are getting more and more attention andrepresent an increasing threat. In this work, we use ComputationTree Logic to model execution paths of the processor cache logicand derive Computation Tree Logic formulas representing vulnera-bilities to cache attacks. Based on the study of cache timing side-channel vulnerabilities, we propose that for existing cache timingside-channel vulnerabilities, a three-step single-cache-block-accessmodel is able to cover all the possibilities for potential attacks. Wepresented 28 types of vulnerabilities based enumeration of all po-tential three-step execution paths, 20 of which map to the knownattack categories or have been previously demonstrated, while 8of which are new. We also show how existing tools for boundedmodel checking can be used with our approach and can help withsecurity veri�cation of processor caches.

7 ACKNOWLEDGEMENTWe would like to thank Professor Ruzica Piskac and Mr. MarkSantolucito for helpful discussions, and the anonymous reviewersfor their feedback on this paper. This work was supported in partby the National Science Foundation’s grant number 1524680.

REFERENCES[1] Onur Acıiçmez and Çetin Kaya Koç. 2006. Trace-driven cache attacks on AES

(short paper). In International Conference on Information and CommunicationsSecurity. Springer, 112–121.

[2] James F Allen. 1984. Towards a general theory of action and time. Arti�cialintelligence 23, 2 (1984), 123–154.

[3] James F Allen. 1990. Maintaining knowledge about temporal intervals. In Readingsin qualitative reasoning about physical systems. Elsevier, 361–372.

[4] Ilan Beer, Shoham Ben-David, Cindy Eisner, and Avner Landver. 1996. RuleBase:An industry-oriented formal veri�cation tool. In Proceedings of the 33rd annualDesign Automation Conference. ACM, 655–660.

[5] Daniel J Bernstein. 2005. Cache-timing attacks on AES. (2005).[6] Armin Biere, Alessandro Cimatti, Edmund Clarke, and Yunshan Zhu. 1999. Sym-

bolic model checking without BDDs. In International conference on tools andalgorithms for the construction and analysis of systems. Springer, 193–207.

[7] Joseph Bonneau and Ilya Mironov. 2006. Cache-collision timing attacks againstAES. In InternationalWorkshop on Cryptographic Hardware and Embedded Systems.Springer, 201–215.

[8] Alessandro Cimatti, Edmund Clarke, Enrico Giunchiglia, Fausto Giunchiglia,Marco Pistore, Marco Roveri, Roberto Sebastiani, and Armando Tacchella. 2002.Nusmv 2: An opensource tool for symbolic model checking. In InternationalConference on Computer Aided Veri�cation. Springer, 359–364.

[9] Edmund M Clarke and E Allen Emerson. 1981. Design and synthesis of synchro-nization skeletons using branching time temporal logic. In Workshop on Logic ofPrograms. Springer, 52–71.

[10] Edmund M. Clarke, E Allen Emerson, and A Prasad Sistla. 1986. Automaticveri�cation of �nite-state concurrent systems using temporal logic speci�cations.ACM Transactions on Programming Languages and Systems (TOPLAS) 8, 2 (1986),244–263.

[11] Michael R Clarkson, Bernd Finkbeiner, Masoud Koleini, Kristopher K Micinski,Markus N Rabe, and César Sánchez. 2014. Temporal logics for hyperproperties.In International Conference on Principles of Security and Trust. Springer, 265–284.

[12] Victor Costan, Ilia A Lebedev, and Srinivas Devadas. 2016. Sanctum: MinimalHardware Extensions for Strong Software Isolation.. In USENIX Security Sympo-sium. 857–874.

[13] Leonid Domnitser, Aamer Jaleel, Jason Loew, Nael Abu-Ghazaleh, and DmitryPonomarev. 2012. Non-monopolizable caches: Low-complexity mitigation ofcache side channel attacks. ACM Transactions on Architecture and Code Optimiza-tion (TACO) 8, 4 (2012), 35.

[14] EAllen Emerson. 1990. Temporal andmodal logic. In FormalModels and Semantics.Elsevier, 995–1072.

[15] E Allen Emerson and Joseph Y Halpern. 1986. “Sometimes” and “not never”revisited: on branching versus linear time temporal logic. Journal of the ACM(JACM) 33, 1 (1986), 151–178.

[16] Qian Ge, Yuval Yarom, David Cock, and Gernot Heiser. 2016. A survey of mi-croarchitectural timing attacks and countermeasures on contemporary hardware.Journal of Cryptographic Engineering (2016), 1–27.

[17] Susanne Graf and Hassen Saïdi. 1997. Construction of abstract state graphs withPVS. In International Conference on Computer Aided Veri�cation. Springer, 72–83.

[18] Daniel Gruss, Clémentine Maurice, Klaus Wagner, and Stefan Mangard. 2016.Flush+ Flush: a fast and stealthy cache attack. In International Conference onDetection of Intrusions and Malware, and Vulnerability Assessment. Springer, 279–299.

[19] Daniel Gruss, Raphael Spreitzer, and Stefan Mangard. 2015. Cache TemplateAttacks: Automating Attacks on Inclusive Last-Level Caches.. In USENIX SecuritySymposium. 897–912.

[20] Roberto Guanciale, Hamed Nemati, Christoph Baumann, and Mads Dam. 2016.Cache storage channels: Alias-driven attacks and veri�ed countermeasures. InSecurity and Privacy (SP), 2016 IEEE Symposium on. IEEE, 38–55.

[21] David Gullasch, Endre Bangerter, and Stephan Krenn. 2011. Cache games–Bringing access-based cache attacks on AES to practice. In Security and Privacy(SP), 2011 IEEE Symposium on. IEEE, 490–505.

[22] Zecheng He and Ruby B Lee. 2017. How secure is your cache against side-channelattacks?. In Proceedings of the 50th Annual IEEE/ACM International Symposiumon Microarchitecture. ACM, 341–353.

[23] Saul Kripke. 2007. Semantical considerations of the modal logic. (2007).[24] Leslie Lamport. 1980. Sometime is sometimes not never: On the temporal logic

of programs. In Proceedings of the 7th ACM SIGPLAN-SIGACT symposium onPrinciples of programming languages. ACM, 174–185.

[25] Kim G Larsen, Paul Pettersson, and Wang Yi. 1997. UPPAAL in a nutshell.International journal on software tools for technology transfer 1, 1-2 (1997), 134–152.

[26] Ruby B Lee, Peter Kwan, John P McGregor, Je�rey Dwoskin, and ZhenghongWang. 2005. Architecture for protecting critical secrets in microprocessors. InACM SIGARCH Computer Architecture News, Vol. 33. IEEE Computer Society,2–13.

[27] Fangfei Liu and Ruby B Lee. 2014. Random �ll cache architecture. In Microarchi-tecture (MICRO), 2014 47th Annual IEEE/ACM International Symposium on. IEEE,203–215.

[28] Yangdi Lyu and Prabhat Mishra. 2017. A Survey of Side-Channel Attacks onCaches and Countermeasures. Journal of Hardware and Systems Security (2017),1–18.

[29] Dag Arne Osvik, Adi Shamir, and Eran Tromer. 2006. Cache attacks and coun-termeasures: the case of AES. In Cryptographers’ Track at the RSA Conference.Springer, 1–20.

[30] Colin Percival. 2005. Cache missing for fun and pro�t.[31] Amir Pnueli. 1977. The temporal logic of programs. In Foundations of Computer

Science, 1977., 18th Annual Symposium on. IEEE, 46–57.[32] Eran Tromer, Dag Arne Osvik, and Adi Shamir. 2010. E�cient cache attacks on

AES, and countermeasures. Journal of Cryptology 23, 1 (2010), 37–71.[33] Yao Wang, Andrew Ferraiuolo, Danfeng Zhang, Andrew C Myers, and G Edward

Suh. 2016. SecDCP: secure dynamic cache partitioning for e�cient timing channelprotection. In Design Automation Conference (DAC), 2016 53nd ACM/EDAC/IEEE.IEEE, 1–6.

[34] Zhenghong Wang and Ruby B Lee. 2007. New cache designs for thwarting soft-ware cache-based side channel attacks. In ACM SIGARCH Computer ArchitectureNews, Vol. 35. ACM, 494–505.

[35] Zhenghong Wang and Ruby B Lee. 2008. A novel cache architecture with en-hanced performance and security. InMicroarchitecture, 2008. MICRO-41. 2008 41stIEEE/ACM International Symposium on. IEEE, 83–93.

[36] Mengjia Yan, Bhargava Gopireddy, Thomas Shull, and Josep Torrellas. 2017.Secure Hierarchy-Aware Cache Replacement Policy (SHARP): Defending AgainstCache-Based Side Channel Attacks. In Proceedings of the 44th Annual InternationalSymposium on Computer Architecture. ACM, 347–360.

[37] Fan Yao, Milos Doroslovacki, and Guru Venkataramani. 2018. Are Coherence Pro-tocol States Vulnerable to Information Leakage?. In High Performance ComputerArchitecture (HPCA), 2018 IEEE International Symposium on. IEEE, 168–179.

[38] Yuval Yarom and Katrina Falkner. 2014. FLUSH+ RELOAD: A High Resolution,Low Noise, L3 Cache Side-Channel Attack.. In USENIX Security Symposium. 719–732.

[39] Danfeng Zhang, Aslan Askarov, and Andrew C Myers. 2012. Language-basedcontrol and mitigation of timing channels. ACM SIGPLAN Notices 47, 6 (2012),99–110.

[40] Danfeng Zhang, Yao Wang, G Edward Suh, and Andrew C Myers. 2015. Ahardware design language for timing-sensitive information-�ow security. InACM SIGARCH Computer Architecture News, Vol. 43. ACM, 503–516.

[41] Tianwei Zhang and Ruby B Lee. 2014. New models of cache architectures char-acterizing information leakage from cache side channels. In Proceedings of the30th Annual Computer Security Applications Conference. ACM, 96–105.

[42] YongBin Zhou and DengGuo Feng. 2005. Side-Channel Attacks: Ten Years AfterIts Publication and the Impacts on Cryptographic Module Security Testing. IACRCryptology ePrint Archive 2005 (2005), 388.