LEASH: Enhancing Micro-architectural Attack Detection with a Reactive Process Scheduler

by   Nikhilesh Singh, et al.

Micro-architectural attacks use information leaked through shared resources to break hardware-enforced isolation. These attacks have been used to steal private information ranging from cryptographic keys to privileged Operating System (OS) data in devices ranging from mobile phones to cloud servers. Most existing software countermeasures either have unacceptable overheads or considerable false positives. Further, they are designed for specific attacks and cannot readily adapt to new variants. In this paper, we propose a framework called LEASH, which works from the OS scheduler to stymie micro-architectural attacks with minimal overheads, negligible impact of false positives, and is capable of handling a wide range of attacks. LEASH works by starving maliciously behaving threads at runtime, providing insufficient time and resources to carry out an attack. The CPU allocation for a falsely flagged thread found to be benign is boosted to minimize overheads. To demonstrate the framework, we modify Linux's Completely Fair Scheduler with LEASH and evaluate it with seven micro-architectural attacks ranging from Meltdown and Rowhammer to a TLB covert channel. The runtime overheads are evaluated with a range of real-world applications and found to be less than 1



page 7


CVA6's Data cache: Structure and Behavior

Since Spectre and Meltdown's disclosure in 2018, a new category of attac...

Towards Constant-Time Foundations for the New Spectre Era

The constant-time discipline is a software-based countermeasure used for...

SPEECHMINER: A Framework for Investigating and Measuring Speculative Execution Vulnerabilities

SPEculative Execution side Channel Hardware (SPEECH) Vulnerabilities hav...

Provably Secure Isolation for Interruptible Enclaved Execution on Small Microprocessors: Extended Version

Computer systems often provide hardware support for isolation mechanisms...

Volcano: Stateless Cache Side-channel Attack by Exploiting Mesh Interconnect

Cache side-channel attacks lead to severe security threats to the settin...

Repttack: Exploiting Cloud Schedulers to Guide Co-Location Attacks

Cloud computing paradigms have emerged as a major facility to store and ...

You Shall Not Bypass: Employing data dependencies to prevent Bounds Check Bypass

A recent discovery of a new class of microarchitectural attacks called S...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

For several years, computer systems designers have relied on traditional hardware mechanisms such as protection rings, segmentation, page tables, and enclaves, to isolate software entities executing in a CPU. These isolation mechanisms have been considerably weakened by a potent class of side-channel attacks known as micro-architectural attacks. A micro-architectural attack makes use of shared hardware resources to leak information across isolation boundaries. They have been used in a variety of applications, from creating covert channels [28], retrieving secret keys of ciphers [9, 56], reading Operating System data [34, 39], fingerprinting websites [64], logging keystrokes [62]

, reverse engineering Deep Learning algorithms 

[26], and breaking Address Space Layout Randomization [7, 23]

. The last couple of years have seen these attack vectors applied on a range of devices from mobile phones 

[38] to third-party cloud platforms [62]. They have been used to leak secrets stored in Trusted Execution Environments like SGX [11] and Trustzone [77] and attack remote computers using webpages that host malicious Javascript [53] or Web-assembly [21].

(a) LEASH stymies micro-architectural attacks by detecting malicious behavior in programs and reducing its CPU-share, thereby reducing the leakage from the shared resource.
(b) LEASH detects malicious behavior by monitoring run time characteristics of all threads () in the system using HPCs. Threads with a high threat index get less CPU time. Thread has persistent malicious behavior and hence gets throttled. Thread

gets flagged for an epoch but recovers, while thread

remains unaffected.
Figure 3: A high-level overview of  LEASH.

In a typical micro-architectural attack, the attacker runs a program called the spy that contends with a victim program for shared hardware resources such as a common Cache Memory [1, 24, 38, 41, 56], Branch Prediction Unit (BPU) [2, 19], Translation Lookaside Buffer (TLB) [22], or DRAM [33, 57]. The contention affects the spy’s execution time in a manner that correlates with the victim’s execution. If the victim’s execution pattern happens to depend on secret data, then, the correlation can be used to reveal it.

Most schemes to prevent micro-architectural attacks work either in the software or are incorporated in the hardware. Hardware solutions include bypassing [73] or partitioning [31, 40, 70] the shared resource, or randomizing accesses to it [58, 59, 70]. The preventive solutions in software attempt to have constant-time implementations [76] or inject noise in measurements to make the attack difficult [27, 42]. While software solutions have huge overheads and may be environment specific, hardware solutions are not applicable to legacy systems.

An alternate approach that promises to solve these problems is to detect and thwart an attack in real time. The detection is typically done using performance monitoring registers in the CPU called Hardware Performance Counters (HPCs) [4, 6, 12, 14, 47, 78]. On detection, the malicious-behaving thread is terminated or rescheduled to a different CPU. A severe limitation of current detection schemes is the false positives due to which benign processes are falsely flagged malicious. Contemporary works [4, 14, 47, 49, 78]

attempt to reduce false positives by deploying complex Machine Learning models. While this increases overheads, the impact of the false positive rate is still unacceptably high. This limitation is exacerbated by the fact that a micro-architectural attack occurs rarely compared to the number of benign programs executing. Thus, these detection techniques more often impact benign program execution than mitigate an attack.

In this paper, we present a micro-architectural attack detection countermeasure called  LEASH that has all the advantages of detection countermeasures with almost no impact of false positives.  LEASH makes use of the observation that a spy thread in a micro-architectural attack needs to contend with the victim for a shared resource. The success of the attack depends on the extent to which the spy can force this contention. If the spy gets insufficient time to execute on the CPU, then the information leakage is reduced, stymieing the attack. Figure ((a)a) provides an analogy.

The LEASH framework works from the Operating System (OS) scheduler. At every context switch, it uses the HPCs to quantify the malicious behavior of each thread in the system using a metric called threat index. It then allocates CPU resources for the thread based on its threat index. A high value of threat index indicates that the process gets less CPU time. For instance, in Figure ((b)b) thread has a threat index that continuously increases. The time slice it obtains for execution correspondingly reduces. If the thread were indeed a micro-architectural attack, the lesser CPU time would clamp the amount of information that is leaked from the victim, thus stymieing the attack.

A significant advantage of LEASH is in its handling of false detection. Suppose a benign thread temporarily exhibits malicious behavior, its CPU quota falls temporarily, and over time it regains its full CPU quota. Thread in Figure ((b)b) demonstrates this recovery after the 4-th epoch. This is unlike contemporary works [4, 14, 47, 49, 78], where a false detection has adverse irreversible effects. With LEASH , the false detection would only result in a small overhead. With the wide range of benchmarks we evaluated, the performance overheads were found to be less than 1% on average.

The important contributions of this paper are as follows:

  • [wide,labelwidth=!,labelindent=1pt]

  • LEASH is an OS scheduler based countermeasure for micro-architectural attacks that has low overheads and negligible impact of false positives. It can support a variety of micro-architectural attacks and can easily adapt to new variants.The framework is highly versatile and can be tuned to detect multiple different attacks simultaneously. It is designed to provide quick response, while still having features for sophisticated add-ons that can detect complex scenarios.

  • We modify Linux’s Completely Fair Scheduler (CFS) with LEASH and evaluate its effectiveness with seven micro-architectural attacks including Prime+Probe on the L1 Data [54], L1 Instruction [1], and LLC caches [75]; L1 and TLB Evict+Time attacks [22, 54], Rowhammer [63, 33], Meltdown [45, 39]. The entire framework just adds around 20 lines of C code in the Linux kernel to provide micro-architectural security for the entire system.

  • We have evaluated LEASH with multiple benchmark suites including the SPEC-2017 [13], SPEC-2006 [66], SPECViewperf-13 [65] and STREAM [44] and found an average perfomance overhead of 1%.

The rest of the paper is organized as follows. Section 2 presents the necessary background on micro-architectural attacks, Hardware Performance Counters, and Linux scheduler. In Section 3, we discuss the related works in micro-architectural attack mitigation. Section 4 sums the key idea in the LEASH framework. In Sections 5 and 6 we discuss the implementation details and present the evaluation and results, respectively. Section 7 discusses the caveats and limitations of LEASH . Section 8 concludes the paper.

2 Background

2.1 Micro-architectural attacks

A micro-architectural side-channel attack leverages leakage from shared micro-architectural resources in a system to glean sensitive information from a process. We illustrate a micro-architectural attack that uses a shared L1-data cache to create a covert channel between a sender and a receiver process. Apriori, the sender and receiver agree upon two cache sets for communicating 0 and 1 respectively. The receiver first performs memory operations that fill both cache sets. This is known as the prime phase. Depending on the message bit, the sender performs a memory operation to evict the receiver’s data from the corresponding cache set. In the probe phase, the receiver performs the memory operations again and times the accesses. Based on the access time, the receiver can infer the transmitted bit since the memory access to the evicted cache set would take longer owing to the cache miss.

Later in the paper, we use this covert channel as a running example to explain LEASH and show how the transmission-rate between sender and receiver can be reduced by throttling the receiver’s CPU time. Further, we apply LEASH to other micro-architectural attacks, including Meltdown [45, 39], Rowhammer [63, 33], L1 data cache attacks on AES [54], L1 instruction cache attacks on RSA [1], a TLB covert channel [22] and a prime-and-probe LLC covert channel [75].

2.2 Hardware Performance Counters

Most modern processors have a Performance Monitoring Unit on-chip to monitor micro-architectural events of running applications. Each logical core has a dedicated set of 4 to 8 configurable registers that can count the number of times a particular event occurs in a given duration. These registers are called Hardware Performance Counters (HPCs) and can be used to monitor a wide range of events like CPU-cycles, cache accesses, context-switches, and page faults. The number of such events that can be monitored simultaneously is limited by the number of HPCs available in the hardware.

Patterns present in the time series traces of performance counter events have been shown to characterize the behavior of a thread’s execution. This has been leveraged in several applications such as detecting anomalous behavior in programs [36, 67, 72], side-channel attacks [6, 14, 47, 78] and malware analysis [8, 17, 67]. LEASH, similarly uses HPCs to compute a threat index for a thread. Threads which depict a micro-architectural attack like behavior are given a high threat index and are throttled by reducing their CPU time.

2.3 Process Scheduling

LEASH modifies the OS scheduling algorithm to consider the threat index of a thread for CPU resource allocation. While we can incorporate LEASH in most scheduling algorithms, in this paper, we demonstrate  LEASH with the Completely Fair Scheduler (CFS); the default scheduler present in the Linux kernel since Version 2.6 [37].

The CFS algorithm tries to achieve the ideal multitasking environment where threads with equal priorities receive the same share of processor time, called timeslice. The timeslice allocated to a thread , denoted , is a fraction of a predefined value called targeted latency (). When multiple threads compete for CPU time, the scheduler allocate timeslices in proportion to a metric called weight of the thread as follows


where is the weight of the thread , is the sum of weights of all the threads sharing the CPU, and is the relative weight of thread . On thread creation, its weight takes a default value () which lies in the middle of 40 discrete levels, ranging from to . The ratio of weights at two consecutive levels , is determined by the OS scheduler at design time. The relationship between these weight levels can be given as . The weight also gives a notion of thread priorities. A higher weight value for thread implies a larger timeslice and a higher frequency of getting scheduled for execution.

3 Related work

There is a pressing need to develop lightweight, portable solutions for micro-architectural attacks. Most preventive countermeasures that have low overheads require hardware modifications [18, 31, 35, 40, 51, 55, 58, 59, 68, 71, 73] and cannot be incorporated in existing systems. To achieve portability, there have been a few attempts to tackle micro-architectural attacks from the Operating System, such as flushing shared resources [15, 28] and soft isolation of Virtual Machines sharing the same hardware [69]. Nomani and Szefer in [50]

incorporate a neural-network within the OS scheduler, to detect tasks requiring the same functional units and scheduling them on different cores to minimize contention. Such solutions are likely to have scalability issues as the workloads increase.

Most contemporary detection-based solutions use HPCs and Machine Learning (ML) models  [4, 14, 47, 48, 49]. Among the several shortcomings [16]

of these works, the most serious limitation is with the false positives which adversely affect benign program execution. Contemporary works use complex techniques like KNNs, decision trees, neural networks and ensemble methods to reduce false positives which can still have unacceptable impacts. Furthermore, the complex techniques used have considerable overheads and could reduce the prediction rate leading to fast attacks completing undetected. Unlike these works,

LEASH reacts to a flagged program by throttling its CPU-share, thus preventing the attack from completing. Contemporary works, on the other hand, would either migrate the program to another CPU or terminate it. The advantage we achieve with the feedback loop of LEASH is that falsely flagged threads can recover and regain their CPU-share with only slight increase in execution time. Further, due to the reactive control loop, very simple detection mechanisms are sufficient.

4 The  Leash Framework

Figure 4: Effects of CPU-share to the receiver thread on the L1-data cache covert channel’s Bandwidth and Error rate. LEASH uses this as a premise to throttle attack programs on detection.
Figure 5: The LEASH reactive loop. The Sensor logs the HPC values for a thread in and passes it to the Detector which computes the threat index for . It then passes the threat index and the mean of to the Supervisor which adjusts the control value for the next epoch, and to the Actuator which updates the weight of as per its threat index. This loop continues throughout the runtime of .

Micro-architectural attacks depend considerably on CPU resources. If the attack programs are starved of the CPU, the success drops considerably. Consider, for example, the L1-cache timing covert channel discussed in Section 2.1. Figure 4 shows that starving the receiver thread not only reduces the communication bandwidth considerably but also increases the transmission errors. The reduced bandwidth and the increased error is due to smaller CPU-time shares, which prevents the receiver from performing a sufficient number of timing measurements.

Along with being highly CPU-bound, micro-architectural attacks are procedural and repetitive by design, which gives them a distinct execution behavior. For example, the receiver in the cache covert channel continuously executes a small set of instructions in a loop performing extensive memory operations. Due to the continuous probing, the number of memory accesses by the receiver increases to be significantly higher compared to a regular thread.  LEASH uses HPCs to detect such anomalous behavior and penalizes such threads by decreasing their weight, which in turn reduces their timeslice (Equation 1). If the thread stops exhibiting the anomalous behavior, its weight is gradually increased, thus regaining its regular timeslice. To achieve this, LEASH has four components: a Sensor, Detector , Actuator , and a Supervisor as shown in Figure 5.


At every context switch, LEASH reads the values of HPCs and logs the event counts since the last context switch. The log is stored in a buffer of size , called , in the context of the scheduled-out thread. Thus, every thread executing in the CPU has a time-series trace for each HPC logged during its execution. For example, the first row in Figure 6 shows the partial time-series traces for the L1-D covert channel described in Section 2.1 and the bzip2 application from the SPEC-2006 benchmark suite. The counter corresponds to an event that counts the delay cycles due to DSB (Decoded Stream Buffer) to MITE (Micro Instruction Translation Engine) switches on an Intel i7-3770 processor.

Figure 6:  LEASH framework effects on an L1-data cache covert channel (left column) and a benign program bzip2 (right column) from the SPEC-2006 benchmark suite.

The counters to log are determined prior to the deployment of  LEASH based on the execution characteristics of the attack vectors considered. The number of counters that can be logged is bounded by the number of available HPC registers in the hardware. Reducing the number of HPCs logged would reduce context-switch overheads, while increasing the number of HPCs logged would widen the scope of the attacks that can be detected. Section 5 discusses this further.

Initial State: At , and . Global: Event count threshold: , default weight: . Input: Thread .
Result: Threat index for -th epoch: ,
1 begin
3       if  then
             = + // threat index update
5             if  then
                   // Thread is unflagged
8      if ( and )  then
             // Thread is flagged
10      return
Algorithm 1 Detector component in LEASH for thread at the beginning of the -th epoch.


At every context switches (called an epoch) for the thread, the Detector is triggered and uses Algorithm 1 to compute the new threat index for the thread. The threat index in the -th epoch depends on the mean of the values (), the event-specific threshold (), the threat index of the previous epoch and the control value passed by the Supervisor function as,


LEASH flags threads which begin to behave maliciously (Line 11 in Algorithm 1). This happens when the mean of an unflagged thread first violates the threshold. For every subsequent epoch for this thread, where exceeds the threshold, its threat index is modified as per the output of the Supervisor function described in Equation 5 (Line 6). LEASH allows a flagged thread to recover if it stops behaving maliciously. The recovery starts when for the flagged thread first falls below the threshold. The thread’s threat index is then reduced in subsequent epochs until the thread reattains the default weight, which restores its CPU share. When this happens, the thread is unflagged and its threat index is reset (Lines 8 and 9).

Figure 6 shows two threads, a L1 Data Cache Covert Channel and a benign program bzip2 from the SPEC-2006 [66] benchmark suite. While both threads, with counter values greater than the threshold get flagged by LEASH , the benign thread bzip2 recovers its fair share of CPU resources (in the 14th epoch) when its counter values go below the threshold. The CPU share for the covert channel is never restored as its counter values always remains over the threshold. Thus the covert channel is never unflagged. Its threat index saturates when the minimum weight is reached.


For each thread in the -th epoch, the Actuator receives the threat index from the Detector and modifies the thread’s weight and in turn, the relative weight (Equation 1) for the thread. The relative weight for the thread at the beginning of the -the epoch is given as


where is , (0 < < 1) is a constant fixed by the OS scheduler which determines the amount of fall in the weight with every increase in the threat index. In our evaluation platform, which means that, for every rise in threat index values, the weight drops by 10% until it reaches . Similarly, when a thread is recovering, the threat index value is negative and hence every fall in threat index value increases its weight by 10% until its weight is restored. The adaptable design of LEASH efficiently brings down the cost of a false penalization. Once a benign thread, which is erroneously flagged, is unflagged, it regains its CPU share and executes without any additional overheads.


LEASH’s Detector identifies threads that are penalized and rewarded. Ideally, this decision should be based on careful analysis of the data so that malicious threads are quickly identified and penalized while benign threads are not affected. However, supporting sophisticated analysis in the Detector is difficult because it executes in a context switch and therefore affects the performance of the entire system. Thus, as seen in Algorithm 1, the Detector is kept very simple and comprises of about 6 instructions that are executed at every epoch ( context switches).

To support complex analysis on the performance counter data, LEASH uses a Supervisor that does not need to execute in the context switch. The Supervisor provides thread specific control value that represents the amount by which the thread index of a flagged thread is degraded or upgraded in the -th epoch. The output of the for a thread is given by


A general framework for the Supervisor function for thread involves a penalty function and reward function , as given in Equation( 5). Such a design allows the Supervisor to be implemented with different policies


where is the mean of and is the threshold. Configurable Supervisor policies allow LEASH to handle new attack vectors. Section 5.3 provides more details about the Supervisor.

5 Implementation

This section provides the implementation details of LEASH and some of its primary design choices.

5.1 Sensing Program Behavior

Most modern processors have 4 to 8 Hardware Performance Counters (HPCs) per logical core that can be configured to count one of several micro-architectural events such as cache misses, branch events, or loads and stores to various levels of memory. To enhance readability, we label 40 selected events as in the paper. We describe these events and associated masks defined by the micro-architecture in detail in the Appendix.

5.2 Enhancing the CFS Scheduler for Leash

Input: Task getting preempted from runqueue by task , per thread counter to log the number of context switches.
Result: : reweighed, scheduled, Logged HPC data for both
1 begin
2       if  threads in and  then
3             wake up dummy thread
4      if   then
5             read event count  
7             increment
8      if  then
             // Algorithm 1
9             Reset ,
10      CFS context switching steps  
11       read event count 
12       return
Algorithm 2 Context Switching in LEASH

In the Linux kernel’s CFS implementation, the context switch is implemented in a function called 111This function is defined in kernel/sched/core.c in the kernel source.. The function switches context from a thread called to a thread called as shown in Algorithm 2. To support LEASH, the function is modified to perform three additional operations; (a) it schedules a dummy thread if needed; (b) it logs the performance counter data in the scheduled out thread’s task structure; and (c) it executes the detector when the gets full. We describe each of these operations.

Dummy Thread.

As described in Equation (1), the targeted latency is shared among the threads in the Run Queue (), proportional to their weights. However, when there is only one thread in the Run Queue, the timeslice it receives is equal to and is independent of the weight. Penalizing the thread, in this case, does not affect the timeslice.

To solve this, LEASH uses a special thread called dummy thread. The thread starts when the system boots, runs an infinite loop in privileged mode. It is signaled to wake up only when the Run Queue has exactly one thread and that is flagged (Lines 2-3 in Algorithm 2). In all other cases, the dummy task continues to sleep. The dummy task thus ensures that the weights of a thread always influence its timeslice.

Figure 7: The number of additional instructions executed per context switch and L1-data cache covert channel bandwidth with different values .
Attack Leaking Strategy Example Event(s)
Component to detect the attack
L1-D cache Covert Channel [54] L1-D cache Prime+Probe : cycles for which the instruction decode queue is empty, or : writebacks from L1D to L2 cache lines in modified coherency state.
L1-D cache attack on AES [54] L1-D cache Evict+Time , or : L2 store read for ownership (RFO) requests from the thread.
L1-I cache attack on RSA [3, 1] L1-I cache Prime+Probe : the number of prefetcher requests that miss the L2 cache, or : the number of instruction cache misses,
LLC Covert Channel [75] LLC Prime+Probe , or : the cache misses for references to the LLC
Meltdown [45, 39] Memory Flush+Reload : the mispredicted branch instructions at retirement, or : direct and indirect near call instructions
Rowhammer [63, 33] DRAM Hammer access , or : the dirty L2 cache lines evicted by demand.
TLB Covert channel [22] TLB Evict+Time : the misses in all TLB levels
Table 1: Micro-architectural attacks evaluated; their leaking component; and the attack strategy used. For our evaluation we have used , , , and .

Log Buffer.

The log buffer, , is a per-thread buffer of size . It logs the event counter values and when full, marks the end of an epoch and triggers the Detector. The value of directly affects the overheads and effectiveness of LEASH. Figure 7 shows how the average overhead per context switch decreases with an increase in . This is because a small , implies more frequent calls to the Detector (Lines 9-10 in Algorithm 2), increasing the amortized number of additional instructions executed per context-switch.

A small value of also allows LEASH to perform the detection of malicious threads at a finer granularity. Figure 7 shows that as increases, the bandwidth of the covert channel also increases. This is because the coarse detection granularity allows the covert channel to execute for sufficient time to transfer information from sender to receiver. As seen in the Figure 7, a buffer size between 16 and 64 entries provides a good trade-off between the overheads and the effectiveness of LEASH.

Figure 8: The threat index and weight of violating the event threshold for a few epochs, with Static and Adaptive Supervisor policies.

5.3 Supervisor Policy

The Supervisor in LEASH manages the control values, as shown in Equation (5). Algorithm 1 shows how these values affect the threat index and, in turn, the weight of a flagged thread. The key components of the Supervisor are the penalty () and reward () functions that respectively provide the rate of degradation and recovery for a flagged thread.

The penalty and reward functions are pluggable. The simplest form is a static policy, where the outputs of the functions are constants. Such a policy is agnostic to the thread execution history. In contrast, an adaptive policy uses the thread execution history. An example of such policy is and which increments the penalty values every flagged epoch and the reward value every recovering epoch. Figure 8, shows the difference between the two policies for a fragment of the benign bzip2 execution, where the counter briefly crossed the threshold for seven epochs. With the static policy, the threat index is increased with the same rate, independent of the previous epochs. Similarly, when the counter drops below the threshold, the threat index decreases with the same rate until the thread is unflagged. With the adaptive policy, the output of and hence the rate of increase of threat index (Algorithm 1), is incremented in every flagged epoch. Similarly, when the counter drops below the threshold, the threat_index is reduced much more quickly. As seen in Figure 8, recovery for this benign thread takes 2 epochs less compared to the static policy.

6 Evaluation and Results

Every micro-architectural attack is characterized by two aspects. The first is the micro-architectural component that leaks information, for example, shared resources like the L1 data [9, 54] and instruction [1] caches, the Last Level Cache (LLC) [41, 74, 75], Translation Lookaside Buffer (TLB) [22], DRAM [33], and Branch Prediction Units (BPU) [19, 10]. The second is the attack strategy used to extract information from the leaking resources. Several strategies such as Prime+Probe [3, 1, 41], Evict+Time [32, 29], Flush+Reload [74], and time-driven attacks [9, 19] have been proposed for this purpose. We evaluate LEASH with seven different micro-architectural attacks chosen to get a wide coverage of leaking components and attack strategies. Table 1 provides the details of attacks evaluated with some example events to detect them. Further in this section we discuss the deployment of LEASH on a system and present the evaluation results for various attacks. We then present the overheads on various workloads including the SPEC-2006 [66], SPEC-2017 [13], SPECViewperf-13 [65] and STREAM [44] benchmark suites.

Figure 9: A heatmap of the Detectability Score of 40 selected events for each of the attacks in Table 1. Identically annotated events for multiple attacks can be used to detect all those attacks, such as event for Rowhammer and Meltdown.
(a) L1-data cache attack on AES
(b) L1-instruction cache attack on RSA
(c) LLC covert channel transmitting 10 bits.
(d) Rowhammer for 200 iterations
(e) Meltdown
(f) TLB covert channel
Figure 16: The effects of LEASH on different attacks.

The evaluation is done on an Intel Core i7-3770 processor, which deploys Intel’s Ivy Bridge micro-architecture. The processor has four physical cores, each with two hyperthreads. We patch the Linux kernel, version 4.19.2, with  LEASH and boot Ubuntu 16.04 Operating System. We configure LEASH with an adaptive Supervisor policy with and (Section  5.3) for the evaluation.

6.1 Deploying Leash

Prior to the deployment of LEASH on a system, the designer models the threat in terms of a set of attack vectors. Events need to be chosen to detect all attack vectors in the set. While typical microprocessors have a large number of countable events, they have a limited number of configurable Hardware Performance Counter (HPC) registers. Our evaluation platform for instance, has 208 events and four configurable HPC registers [30]. The designer thus has to choose at most four events that can best distinguish the set of attacks from benign programs. In the subsequent sections, we present techniques to choose such events and the evaluation results.

Selecting HPCs.

As a representative for benign programs, we use all programs of a CPU benchmark suite that we assume cover a variety of benign program behavior. For each micro-architectural attack, we analyze all supported events and rank them based on distinguishability from the benign set using Principal Component Analysis 

[20]. Figure 9 summarises the distinguishability score for the 7 attack vectors in Table 1 using SPEC-2006 CPU benchmark suite as the set of benign programs [66] for the best 40 events of the 208 supported on our platform. Since there are only 4 HPC registers available, we configure at most 4 events that can best distinguish the 7 attacks. From Figure 9, we notice that events , , , and satisfy this requirement. Event covers attacks Meltdown and Rowhammer event covers attacks L1-I Cache attack and TLB Covert Channel, event covers attacks L1-D Cover Channel and L1-D attack on AES while the event can cover the attacks LLC Covert Channel and Rowhammer. Many other such event combinations are also possible.

Detecting Attacks.

LEASH is able to throttle all the attacks in Table 1. Figure 16 describes the impact of LEASH on these attacks. For example, the guessing entropy [43] for 1 byte of an T-table based AES key [52], using the L1-D Evict+Time attack increases from 10 to 131 (Figure (a)a). The error in guessing 1-bit of an RSA key used in a square-and-multiply implementation [46] increases to 50% (Figure (b)b). In both cases, the attacks are as good as an attacker that randomly guesses the key. The covert channels at LLC [75] and TLB [22] see a drastic fall in the number of bits communicated after getting throttled by LEASH (Figure (c)c and  (f)f). The Rowhammer [63] attack, which induces a bit-flip in a DRAM222 Transcend -1333 645927-0350 DRAM chip. row every 29 iterations (on average) is unable to cause a single bit-flip even after a day of execution (Figure (d)d). Further, the Meltdown [45] attack that dumps contents of the kernel memory, is throttled by LEASH to become ineffective (Figure (e)e).

LEASH with Attack Variants.

While configuring LEASH, events are chosen by profiling a specific realization of an attack. However, with the same configuration LEASH can detect different variants of the attacks as well. For example, the covert channel described in Section 2.1, can have multiple variants by tweaking the communication protocol. For example, we design a , which transmits redundant bits for reliability while a , which uses multiple sets to transmit two bits at a time. LEASH can detect these variants of the covert channel as seen in Figure 17. Without LEASH, the bandwidth is 0.43 bits/second for the base variant, 1.76 bits/second for and to 0.087 bits/second for . With LEASH, all three covert channels are stymied and almost no bit gets transmitted correctly.

Figure 17: Effects of LEASH on multiple variants of the L1-data cache covert channel transmitting 30 bits.

6.2 Performance Overheads

We evaluated LEASH with several benchmark suites including SPEC-2006 [66], SPEC-2017 [13], SPECViewperf-13 [65] and STREAM [44]. SPEC-2006 and SPEC-2017 are CPU benchmark suites with different integer and floating-point programs like Machine Learning algorithms. SPECViewperf-13 is a collection of graphics-oriented benchmarks programs, while STREAM is designed to perform memory-intestive tasks. The overheads seen in Figure 18 is due to (1) the few additional instructions in each context switch (Figure 7) and (2) benign threads being falsely flagged. In contrast to contemporary detection counter-measures [4, 6, 12, 14, 47, 78], all falsely flagged programs recover and are not adversely affected. The only case where over 25% overheads occurs is blender_r, a 3D rendering program, which is falsely flagged in 30% of its epochs due to the prolonged malicious looking behavior. Out of the programs evaluated, over 45% were flagged at-least once. However, run-time overheads on average across all benchmarks remain low at 1%. Another reason for the low overheads is that LEASH executes during a context switch in the kernel. Unlike  [6, 12, 14, 47, 78], it does not require a background task that needs scheduling and is independent of the system load.

Figure 18: Performance overheads due to LEASH on various benchmark suites.

7 Caveats and Limitations

  • [wide,labelwidth=!,labelindent=0pt]

  • Time-Driven Attacks. Unlike the attacks discussed in Section 6, in a time-driven attack, the attacker uses the victim’s execution time [10, 60, 61].LEASH can not detect such attacks because of the absence of a spy thread to flag.

  • High-resolution Attacks. If a high-resolution attack like [5] works in less time than an epoch, LEASH would not be able to stop it unless the epoch is shortened. However, this can increase the overheads (Figure 7).

  • Undetectable Attacks. While the attacks evaluated were identifiable by HPCs, there may be attacks that evade them. LEASH would not be able to thwart such attacks.

  • Complex adversarial attacks on LEASH. While the Supervisor component in LEASH can be designed to detect multiple adversarial attacks, there may be complex strategies such as using distributed colluding threads  [25]. The Supervisor would need to be enhanced to handle such distributed attacks.

  • Detecting a large number of attacks. As the attack vectors to detect increase, the number of events to be counted may exceed the HPCs available in the hardware, requiring multiplexing.This may increase context switch times and reduce the precision of the results.

8 Conclusions

Detection based countermeasures for micro-architectural attacks are promising as they can adapt easily to a wide range of attacks. However, a major shortcoming is the unacceptably high false positive rate. Contemporary research attempts to address this limitation on by deploying sophisticated analysis techniques. While this has found to only marginally improve false positives, the overheads and latencies are affected considerably due to complex techniques used. Unlike these approaches, the reactive design of LEASH facilitates lightweight analysis which allows falsely flagged threads to recover quickly with minimum overheads of less than 1% while still accurately detecting attacks. To the best of our knowledge, LEASH is the first reactive countermeasure for micro-architectural attacks in the Operating System scheduler and is therefore, invariant to system load. Additionally, it just adds around 15 instructions per context switch thus has a negligible impact on context switch latencies. It thus opens avenues to security aware OS scheduler designs.


  • [1] O. Aciiçmez, B. B. Brumley, and P. Grabher (2010) New results on instruction cache attacks. In Cryptographic Hardware and Embedded Systems, CHES 2010, 12th International Workshop, Santa Barbara, CA, USA, August 17-20, 2010. Proceedings, pp. 110–124. External Links: Link, Document Cited by: 2nd item, §1, §2.1, Table 1, §6.
  • [2] O. Aciiçmez, Ç. K. Koç, and J. Seifert (2007) Predicting secret keys via branch prediction. In Topics in Cryptology - CT-RSA 2007, The Cryptographers’ Track at the RSA Conference 2007, San Francisco, CA, USA, February 5-9, 2007, Proceedings, pp. 225–242. External Links: Link, Document Cited by: §1.
  • [3] O. Aciiçmez (2007) Yet another microarchitectural attack: : exploiting i-cache. In Proceedings of the 2007 ACM workshop on Computer Security Architecture, CSAW 2007, Fairfax, VA, USA, November 2, 2007, pp. 11–18. External Links: Link, Document Cited by: Table 1, §6.
  • [4] M. Alam, S. Bhattacharya, D. Mukhopadhyay, and S. Bhattacharya (2017) Performance counters to rescue: A machine learning based safeguard against micro-architectural side-channel-attacks. IACR Cryptology ePrint Archive 2017, pp. 564. External Links: Link Cited by: §1, §1, §3, §6.2.
  • [5] G. I. Apecechea, M. S. Inci, T. Eisenbarth, and B. Sunar (2014) Wait a minute! A fast, cross-vm attack on AES. In Research in Attacks, Intrusions and Defenses - 17th International Symposium, RAID 2014, Gothenburg, Sweden, September 17-19, 2014. Proceedings, A. Stavrou, H. Bos, and G. Portokalidis (Eds.), Lecture Notes in Computer Science, Vol. 8688, pp. 299–319. External Links: Link, Document Cited by: 2nd item.
  • [6] Z. B. Aweke, S. F. Yitbarek, R. Qiao, R. Das, M. Hicks, Y. Oren, and T. Austin (2016) ANVIL: software-based protection against next-generation rowhammer attacks. In Proceedings of the Twenty-First International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’16, New York, NY, USA, pp. 743–755. External Links: ISBN 978-1-4503-4091-5, Link, Document Cited by: §1, §2.2, §6.2.
  • [7] A. Barresi, K. Razavi, M. Payer, and T. R. Gross (2015) CAIN: silently breaking ASLR in the cloud. In 9th USENIX Workshop on Offensive Technologies, WOOT ’15, Washington, DC, USA, August 10-11, 2015., External Links: Link Cited by: §1.
  • [8] K. Basu, P. Krishnamurthy, F. Khorrami, and R. Karri (2020) A theoretical study of hardware performance counters-based malware detection. IEEE Trans. Information Forensics and Security 15, pp. 512–525. External Links: Link, Document Cited by: §2.2.
  • [9] D. J. Bernstein (2005) Cache-timing Attacks on AES. Cited by: §1, §6.
  • [10] S. Bhattacharya and D. Mukhopadhyay (2015) Who watches the watchmen?: utilizing performance monitors for compromising keys of RSA on intel platforms. In Cryptographic Hardware and Embedded Systems - CHES 2015 - 17th International Workshop, Saint-Malo, France, September 13-16, 2015, Proceedings, pp. 248–266. External Links: Link, Document Cited by: §6, 1st item.
  • [11] F. Brasser, U. Müller, A. Dmitrienko, K. Kostiainen, S. Capkun, and A. Sadeghi (2017) Software grand exposure: SGX cache attacks are practical. In Proceedings of the 11th USENIX Conference on Offensive Technologies, WOOT’17, Berkeley, CA, USA, pp. 11–11. External Links: Link Cited by: §1.
  • [12] S. Briongos, G. Irazoqui, P. Malagón, and T. Eisenbarth (2018) CacheShield: detecting cache attacks through self-observation. In Proceedings of the Eighth ACM Conference on Data and Application Security and Privacy, CODASPY 2018, Tempe, AZ, USA, March 19-21, 2018, pp. 224–235. External Links: Link, Document Cited by: §1, §6.2.
  • [13] J. Bucek, K. Lange, and J. v. Kistowski (2018) SPEC cpu2017: next-generation compute benchmark. In Companion of the 2018 ACM/SPEC International Conference on Performance Engineering, ICPE ’18, New York, NY, USA, pp. 41–42. External Links: ISBN 9781450356299, Link, Document Cited by: 3rd item, §6.2, §6.
  • [14] M. Chiappetta, E. Savas, and C. Yilmaz (2016) Real time detection of cache-based side-channel attacks using hardware performance counters. Appl. Soft Comput. 49, pp. 1162–1174. External Links: Link, Document Cited by: §1, §1, §2.2, §3, §6.2.
  • [15] D. Cock (2013)

    Practical probability: applying pgcl to lattice scheduling

    In Interactive Theorem Proving - 4th International Conference, ITP 2013, Rennes, France, July 22-26, 2013. Proceedings, pp. 311–327. External Links: Link, Document Cited by: §3.
  • [16] S. Das, J. Werner, M. Antonakakis, M. Polychronakis, and F. Monrose (2019) SoK: the challenges, pitfalls, and perils of using hardware performance counters for security. In 2019 IEEE Symposium on Security and Privacy, SP 2019, San Francisco, CA, USA, May 19-23, 2019, pp. 20–38. External Links: Link, Document Cited by: §3.
  • [17] J. Demme, M. Maycock, J. Schmitz, A. Tang, A. Waksman, S. Sethumadhavan, and S. J. Stolfo (2013) On the feasibility of online malware detection with performance counters. In The 40th Annual International Symposium on Computer Architecture, ISCA’13, Tel-Aviv, Israel, June 23-27, 2013, pp. 559–570. External Links: Link, Document Cited by: §2.2.
  • [18] L. Domnitser, A. Jaleel, J. Loew, N. B. Abu-Ghazaleh, and D. Ponomarev (2012) Non-monopolizable caches: low-complexity mitigation of cache side channel attacks. TACO 8 (4), pp. 35:1–35:21. External Links: Link, Document Cited by: §3.
  • [19] D. Evtyushkin, R. Riley, N. B. Abu-Ghazaleh, and D. Ponomarev (2018) BranchScope: A new side-channel attack on directional branch predictor. In Proceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS 2018, Williamsburg, VA, USA, March 24-28, 2018, pp. 693–707. External Links: Link, Document Cited by: §1, §6.
  • [20] K. P. F.R.S. (1901) LIII. on lines and planes of closest fit to systems of points in space. The London, Edinburgh, and Dublin Philosophical Magazine and Journal of Science 2 (11), pp. 559–572. External Links: Document Cited by: §6.1.
  • [21] D. Genkin, L. Pachmanov, E. Tromer, and Y. Yarom (2018) Drive-by key-extraction cache attacks from portable code. In Applied Cryptography and Network Security - 16th International Conference, ACNS 2018, Leuven, Belgium, July 2-4, 2018, Proceedings, pp. 83–102. External Links: Link, Document Cited by: §1.
  • [22] B. Gras, K. Razavi, H. Bos, and C. Giuffrida (2018) Translation leak-aside buffer: defeating cache side-channel protections with TLB attacks. In 27th USENIX Security Symposium, USENIX Security 2018, Baltimore, MD, USA, August 15-17, 2018., pp. 955–972. External Links: Link Cited by: 2nd item, §1, §2.1, Table 1, §6.1, §6.
  • [23] B. Gras, K. Razavi, E. Bosman, H. Bos, and C. Giuffrida (2017) ASLR on the line: practical cache attacks on the MMU. In 24th Annual Network and Distributed System Security Symposium, NDSS 2017, San Diego, California, USA, February 26 - March 1, 2017, External Links: Link Cited by: §1.
  • [24] D. Gruss, R. Spreitzer, and S. Mangard (2015) Cache template attacks: automating attacks on inclusive last-level caches. In Proceedings of the 24th USENIX Conference on Security Symposium, SEC’15, Berkeley, CA, USA, pp. 897–912. External Links: ISBN 978-1-931971-232, Link Cited by: §1.
  • [25] D. Gullasch, E. Bangerter, and S. Krenn (2011) Cache games – bringing access-based cache attacks on aes to practice. In Proceedings of the 2011 IEEE Symposium on Security and Privacy, SP ’11, Washington, DC, USA, pp. 490–505. External Links: ISBN 978-0-7695-4402-1, Link, Document Cited by: 4th item.
  • [26] S. Hong, M. Davinroy, Y. Kaya, S. N. Locke, I. Rackow, K. Kulda, D. Dachman-Soled, and T. Dumitras (2018) Security analysis of deep neural networks operating in the presence of cache side-channel attacks. CoRR abs/1810.03487. External Links: Link, 1810.03487 Cited by: §1.
  • [27] W. Hu (1991) Reducing timing channels with fuzzy time. In Proceedings of the 1991 IEEE Symposium on Security and Privacy, Oakland, California, USA, May 20-22, 1991, pp. 8–20. External Links: Link, Document Cited by: §1.
  • [28] W. Hu (1992) Lattice Scheduling and Covert Channels. In Proceedings of the 1992 IEEE Symposium on Security and Privacy, SP ’92, Washington, DC, USA, pp. 52–61. External Links: ISBN 0-8186-2825-1 Cited by: §1, §3.
  • [29] R. Hund, C. Willems, and T. Holz (2013) Practical timing side channel attacks against kernel space aslr. In Proceedings of the 2013 IEEE Symposium on Security and Privacy, SP ’13, USA, pp. 191–205. External Links: ISBN 9780769549774, Link, Document Cited by: §6.
  • [30] (2007-08) Intel 64 and ia-32 architectures software developer’s manual - volume 3b. Intel Corporation. Cited by: §6.1.
  • [31] (2015) Intel CAT: improving real-time performance by utilizing cache allocation technology.. Intel Corporation. Cited by: §1, §3.
  • [32] H. Jain, D. A. Balaraju, and C. Rebeiro (2019) Spy cartel: parallelizing evict+time-based cache attacks on last-level caches. J. Hardware and Systems Security 3 (2), pp. 147–163. External Links: Link, Document Cited by: §6.
  • [33] Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu (2014) Flipping bits in memory without accessing them: an experimental study of dram disturbance errors. In Proceeding of the 41st Annual International Symposium on Computer Architecuture, ISCA ’14, Piscataway, NJ, USA, pp. 361–372. External Links: ISBN 978-1-4799-4394-4, Link Cited by: 2nd item, §1, §2.1, Table 1, §6.
  • [34] P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom (2019) Spectre attacks: exploiting speculative execution. In 40th IEEE Symposium on Security and Privacy (S&P’19), Cited by: §1.
  • [35] J. Kong, O. Aciiçmez, J. Seifert, and H. Zhou (2009) Hardware-software integrated approaches to defend against software cache-based side channel attacks. In 15th International Conference on High-Performance Computer Architecture (HPCA-15 2009), 14-18 February 2009, Raleigh, North Carolina, USA, pp. 393–404. External Links: Link, Document Cited by: §3.
  • [36] P. Krishnamurthy, R. Karri, and F. Khorrami (2020) Anomaly detection in real-time multi-threaded processes using hardware performance counters. IEEE Trans. Information Forensics and Security 15, pp. 666–680. External Links: Link, Document Cited by: §2.2.
  • [37] (2019)(Website) External Links: Link Cited by: §2.3.
  • [38] M. Lipp, D. Gruss, R. Spreitzer, C. Maurice, and S. Mangard (2016) ARMageddon: cache attacks on mobile devices. In Proceedings of the 25th USENIX Conference on Security Symposium, SEC’16, Berkeley, CA, USA, pp. 549–564. External Links: ISBN 978-1-931971-32-4, Link Cited by: §1, §1.
  • [39] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Hamburg (2018) Meltdown: reading kernel memory from user space. In 27th USENIX Security Symposium (USENIX Security 18), Cited by: 2nd item, §1, §2.1, Table 1.
  • [40] F. Liu, Q. Ge, Y. Yarom, F. McKeen, C. V. Rozas, G. Heiser, and R. B. Lee (2016) CATalyst: defeating last-level cache side channel attacks in cloud computing. In 2016 IEEE International Symposium on High Performance Computer Architecture, HPCA 2016, Barcelona, Spain, March 12-16, 2016, pp. 406–418. External Links: Link, Document Cited by: §1, §3.
  • [41] F. Liu, Y. Yarom, Q. Ge, G. Heiser, and R. B. Lee (2015) Last-level cache side-channel attacks are practical. In 2015 IEEE Symposium on Security and Privacy, SP 2015, San Jose, CA, USA, May 17-21, 2015, pp. 605–622. External Links: Link, Document Cited by: §1, §6.
  • [42] R. Martin, J. Demme, and S. Sethumadhavan (2012) TimeWarp: rethinking timekeeping and performance monitoring mechanisms to mitigate side-channel attacks. In 39th International Symposium on Computer Architecture (ISCA 2012), June 9-13, 2012, Portland, OR, USA, pp. 118–129. External Links: Link, Document Cited by: §1.
  • [43] J. L. Massey (1994) Guessing and entropy. In Information Theory, 1994. Proceedings., 1994 IEEE International Symposium on, pp. 204. Cited by: §6.1.
  • [44] J. D. McCalpin (1991-2007) STREAM: sustainable memory bandwidth in high performance computers. Technical report University of Virginia, Charlottesville, Virginia. Note: A continually updated technical report. http://www.cs.virginia.edu/stream/ External Links: Link Cited by: 3rd item, §6.2, §6.
  • [45] Meltdown Implementation - Institute of Applied Information Processing and Communications (IAIK). Note: Accessed: 2020-08-13 External Links: Link Cited by: 2nd item, §2.1, Table 1, §6.1.
  • [46] A. J. Menezes, S. A. Vanstone, and P. C. V. Oorschot (1996) Handbook of applied cryptography. 1st edition, CRC Press, Inc., USA. External Links: ISBN 0849385237 Cited by: §6.1.
  • [47] M. Mushtaq, A. Akram, M. K. Bhatti, M. Chaudhry, V. Lapotre, and G. Gogniat (2018) NIGHTs-watch: a cache-based side-channel intrusion detector using hardware performance counters. In Proceedings of the 7th International Workshop on Hardware and Architectural Support for Security and Privacy, HASP@ISCA 2018, Los Angeles, CA, USA, June 02-02, 2018, pp. 1:1–1:8. External Links: Link, Document Cited by: §1, §1, §2.2, §3, §6.2.
  • [48] M. Mushtaq, A. Akram, M. K. Bhatti, R. N. B. Rais, V. Lapotre, and G. Gogniat (2018) Run-time detection of prime + probe side-channel attack on AES encryption algorithm. In 2018 Global Information Infrastructure and Networking Symposium, GIIS 2018, Thessaloniki, Greece, October 23-25, 2018, pp. 1–5. External Links: Link, Document Cited by: §3.
  • [49] M. Mushtaq, J. Bricq, M. K. Bhatti, A. Akram, V. Lapotre, G. Gogniat, and P. Benoit (2020) WHISPER: A tool for run-time detection of side-channel attacks. IEEE Access 8, pp. 83871–83900. External Links: Link, Document Cited by: §1, §1, §3.
  • [50] J. Nomani and J. Szefer (2015) Predicting program phases and defending against side-channel attacks using hardware performance counters. In Proceedings of the Fourth Workshop on Hardware and Architectural Support for Security and Privacy, HASP@ISCA 2015, Portland, OR, USA, June 14, 2015, pp. 9:1–9:4. External Links: Link, Document Cited by: §3.
  • [51] J. Oberg, S. Meiklejohn, T. Sherwood, and R. Kastner (2013) A practical testing framework for isolating hardware timing channels. In Design, Automation and Test in Europe, DATE 13, Grenoble, France, March 18-22, 2013, pp. 1281–1284. External Links: Link, Document Cited by: §3.
  • [52] OpenSSL T-table implementation of AES. Note: Accessed: 2020-08-13 External Links: Link Cited by: §6.1.
  • [53] Y. Oren, V. P. Kemerlis, S. Sethumadhavan, and A. D. Keromytis (2015) The spy in the sandbox: practical cache attacks in javascript and their implications. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Denver, CO, USA, October 12-16, 2015, pp. 1406–1418. External Links: Link, Document Cited by: §1.
  • [54] D. A. Osvik, A. Shamir, and E. Tromer (2006) Cache attacks and countermeasures: the case of AES. In Topics in Cryptology - CT-RSA 2006, The Cryptographers’ Track at the RSA Conference 2006, San Jose, CA, USA, February 13-17, 2006, Proceedings, pp. 1–20. External Links: Link, Document Cited by: 2nd item, §2.1, Table 1, §6.
  • [55] D. Page (2005) Partitioned cache architecture as a side-channel defence mechanism. IACR Cryptology ePrint Archive 2005, pp. 280. External Links: Link Cited by: §3.
  • [56] C. Percival (2005) Cache Missing for Fun and Profit. In Proc. of BSDCan, Cited by: §1, §1.
  • [57] P. Pessl, D. Gruss, C. Maurice, M. Schwarz, and S. Mangard (2016) DRAMA: exploiting DRAM addressing for cross-cpu attacks. In 25th USENIX Security Symposium, USENIX Security 16, Austin, TX, USA, August 10-12, 2016., pp. 565–581. External Links: Link Cited by: §1.
  • [58] M. K. Qureshi (2018) CEASER: mitigating conflict-based cache attacks via encrypted-address and remapping. In 51st Annual IEEE/ACM International Symposium on Microarchitecture, MICRO 2018, Fukuoka, Japan, October 20-24, 2018, pp. 775–787. External Links: Link, Document Cited by: §1, §3.
  • [59] M. K. Qureshi (2019) New attacks and defense for encrypted-address cache. In Proceedings of the 46th International Symposium on Computer Architecture, ISCA 2019, Phoenix, AZ, USA, June 22-26, 2019, pp. 360–371. External Links: Link, Document Cited by: §1, §3.
  • [60] C. Rebeiro and D. Mukhopadhyay (2012) Boosting profiled cache timing attacks with A priori analysis. IEEE Trans. Information Forensics and Security 7 (6), pp. 1900–1905. External Links: Link, Document Cited by: 1st item.
  • [61] C. Rebeiro and D. Mukhopadhyay (2015) Micro-architectural analysis of time-driven cache attacks: quest for the ideal implementation. IEEE Trans. Computers 64 (3), pp. 778–790. External Links: Link, Document Cited by: 1st item.
  • [62] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage (2009) Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds. In Proceedings of the 2009 ACM Conference on Computer and Communications Security, CCS 2009, Chicago, Illinois, USA, November 9-13, 2009, pp. 199–212. External Links: Link, Document Cited by: §1.
  • [63] Rowhammer test implementation - Google. Note: Accessed: 2020-08-13 External Links: Link Cited by: 2nd item, §2.1, Table 1, §6.1.
  • [64] A. Shusterman, L. Kang, Y. Haskal, Y. Meltser, P. Mittal, Y. Oren, and Y. Yarom (2019) Robust website fingerprinting through the cache occupancy channel. In 28th USENIX Security Symposium, USENIX Security 2019, Santa Clara, CA, USA, August 14-16, 2019., pp. 639–656. External Links: Link Cited by: §1.
  • [65] SPECViewperf 13 Linux Edition Benchmark. External Links: Link Cited by: 3rd item, §6.2, §6.
  • [66] C. D. Spradling (2007-03) SPEC cpu2006 benchmark tools. SIGARCH Comput. Archit. News 35 (1), pp. 130–134. External Links: ISSN 0163-5964, Link, Document Cited by: 3rd item, §4, §6.1, §6.2, §6.
  • [67] A. Tang, S. Sethumadhavan, and S. J. Stolfo (2014) Unsupervised anomaly-based malware detection using hardware features. In Research in Attacks, Intrusions and Defenses - 17th International Symposium, RAID 2014, Gothenburg, Sweden, September 17-19, 2014. Proceedings, pp. 109–129. External Links: Link, Document Cited by: §2.2.
  • [68] M. Tiwari, X. Li, H. M. G. Wassel, F. T. Chong, and T. Sherwood (2009) Execution leases: a hardware-supported mechanism for enforcing strong non-interference. In 42st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO-42 2009), December 12-16, 2009, New York, New York, USA, pp. 493–504. External Links: Link, Document Cited by: §3.
  • [69] V. Varadarajan, T. Ristenpart, and M. M. Swift (2014) Scheduler-based defenses against cross-vm side-channels. In Proceedings of the 23rd USENIX Security Symposium, San Diego, CA, USA, August 20-22, 2014, pp. 687–702. External Links: Link Cited by: §3.
  • [70] Z. Wang and R. B. Lee (2006) Covert and side channels due to processor architecture. In 22nd Annual Computer Security Applications Conference (ACSAC 2006), 11-15 December 2006, Miami Beach, Florida, USA, pp. 473–482. External Links: Link, Document Cited by: §1.
  • [71] Z. Wang and R. B. Lee (2008) A novel cache architecture with enhanced performance and security. In 41st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO-41 2008), November 8-12, 2008, Lake Como, Italy, pp. 83–93. External Links: Link, Document Cited by: §3.
  • [72] L. L. Woo, M. Zwolinski, and B. Halak (2018) Early detection of system-level anomalous behaviour using hardware performance counters. In 2018 Design, Automation & Test in Europe Conference & Exhibition, DATE 2018, Dresden, Germany, March 19-23, 2018, pp. 485–490. External Links: Link, Document Cited by: §2.2.
  • [73] M. Yan, J. Choi, D. Skarlatos, A. Morrison, C. W. Fletcher, and J. Torrellas (2018) InvisiSpec: making speculative execution invisible in the cache hierarchy. In 51st Annual IEEE/ACM International Symposium on Microarchitecture, MICRO 2018, Fukuoka, Japan, October 20-24, 2018, pp. 428–441. External Links: Link, Document Cited by: §1, §3.
  • [74] Y. Yarom and K. Falkner (2014) FLUSH+RELOAD: A high resolution, low noise, L3 cache side-channel attack. In Proceedings of the 23rd USENIX Security Symposium, San Diego, CA, USA, August 20-22, 2014., pp. 719–732. External Links: Link Cited by: §6.
  • [75] Y. Yarom (2016) Mastik: a micro-architectural side-channel toolkit. Cited by: 2nd item, §2.1, Table 1, §6.1, §6.
  • [76] B. Yee, D. Sehr, G. Dardyk, J. B. Chen, R. Muth, T. Ormandy, S. Okasaka, N. Narula, and N. Fullagar (2009) Native client: A sandbox for portable, untrusted x86 native code. In 30th IEEE Symposium on Security and Privacy (S&P 2009), 17-20 May 2009, Oakland, California, USA, pp. 79–93. External Links: Link, Document Cited by: §1.
  • [77] N. Zhang, K. Sun, D. Shands, W. Lou, and Y. T. Hou (2018) TruSense: information leakage from trustzone. In 2018 IEEE Conference on Computer Communications, INFOCOM 2018, Honolulu, HI, USA, April 16-19, 2018, pp. 1097–1105. External Links: Link, Document Cited by: §1.
  • [78] T. Zhang, Y. Zhang, and R. B. Lee (2016) CloudRadar: A real-time side-channel attack detection system in clouds. In Research in Attacks, Intrusions, and Defenses - 19th International Symposium, RAID 2016, Paris, France, September 19-21, 2016, Proceedings, pp. 118–140. External Links: Link, Document Cited by: §1, §1, §2.2, §6.2.