The lab assignment is focused on cache-based hardware side channels. The main goal of the lab is to develop the code of a thief module that will extract the secret key that opens a victim vault. Through the lab, you will develop two cache-based attacks. In both cases, the thief will try to capture the secret from the victim only by observing cache behavior.
In this lab you will extract the secret key that locks the victim vault. You will develop two ways of extracting the vault key: 1) through Flush+Reload with access to the clflush instruction and 2) through Prime+Probe that does not use any special instructions.
The vault is locked with a secret key. Periodically, the owner of the vault uses the key to open it. The goal of the thief is to continuously monitor the caches and detect the key used to open the vault. For the purpose of this lab, you will only get access to the vault binary but not the actual code. To make the lab manageable you will also get the source code for utility functions and a skeleton source code of the thief module. The side-channel attack will target the L2 cache, and the thief and the vault code are sharing a physical core through SMT.
The lab starter code can be downloaded here. The deliverables of this lab assignment are the implementation of the two functions that perform Flush+Reload and Prime+Probe. A 1-2 page report should describe the high-level idea of the code, the processor model, and the measured results for the two attacks (1 figure for each attack). The figure should clearly show the access latency for different cache sets and how the attack is successful. You will also submit your code together with the report. Everything should be submitted on Gradescope.
NOTE: Since we re-use the same lab assignments across years, we ask that you please do not make your lab code publicly accessible (e.g., by checking your solutions into a public repository on GitHub). This helps keep the labs fair and interesting for students in future years.
The following are suggested steps to guide you towards completing the lab assignment.
The homework directory is split into two parts, flush_reload and prime_probe. The lab is composed of the following files:
The measure_line_access_time() function is provided in util.c to measure the memory access time of a cache line. Specifically, the code uses rdtsc wrapped with lfence instructions in order to measure the access time. You can use this function to reliably measure cache access time.
In util.c, void clf lush(ADDR_PTR addr) further provides a wrapper for the x86 clflush instruction. By using these two functionalities you can start developing the first part of the lab assignment based on a Flush+Reload side-channel. For the second part of the lab, based on the Prime+Probe, you are not allowed to use clflush but you can still use the same timing function as provided for the probe phase.
For the Flush+Reload you have access to the source code /flush_reload/vault.c. For convenience the attacker increments the buffer at the location of the key so can you quickly verify the behavior of the victim from the attacker side. The Flush+Reload attack can also work from different cores without SMT. Depending on your implementation and measurements you should justify the access time and at which cache level the attack is performed.
The following code snippet shows the high level behavior of the /prime_probe/vault:
// Set vault_key to random integer in the
// range [0, NUM_L2_CACHE_SETS)
int vault_key = random(0, NUM_L2_CACHE_SETS);
// Find NUM_L2_CACHE_WAYS addresses in mem that all map to the
cache set
// with an index of vault_key to create a partial eviction set
char *eviction_set[NUM_L2_CACHE_WAYS];
char *mem = get_buffer();
get_partial_eviction_set(eviction_set , mem);
// The victim repeatedly opens the vault based
// on the eviction set
while (true) {
for (int i = 0; i < NUM_L2_CACHE_WAYS; i++) {
// Access the eviction address
(*(eviction_set[i]))++;
}
}The vault code after initialization will continuously access the randomly selected eviction set. Every time the program runs a different key will be selected. The vault program will ask for the L2 cache sets and ways according to your system.
Remember that when you are writing your code in C, you are effectively using virtual addresses. While L1 caches in modern processors are indexed by virtual addresses, the L2 cache is indexed by physical addresses. To facilitate the development of your side-channel the provided thief code already allocates 2MB huge pages. This will allow you to control the indexing function of the L2 caches. The same is also true for the vault code. Note that, this is done with the madvise system call. As a result, when you are running both the vault and the thief binaries make sure that huge pages are actually allocated. Both the vault and thief code allocate a single huge page. The allocation happens after the write to the page (already included in the code).
To monitor the use of huge pages you can use cat /proc/meminfo -- grep Huge. Huge pages in use are shown under AnonHugePages. You can also list the processes using huge pages with the following command: grep -e AnonHugePages -s /proc/*/smaps | awk '{if($2>0) print $0}'.
Before designing your side-channel attacks you will need to modify the params.h file with the appropriate parameters for your system. You can use any system utility you want. For example /proc/cpuinfo is simple source to get the required information.
In order to simplify the Prime+Probe attack, we will target the L2 cache. To be able to get measurements you will need to run the vault and the thief binaries on the two sibling SMT threads (hyperthreads) of a physical core. You can track the hyperthread numbers based on the processor model you are using through /proc/cpuinfo. The Makefile already includes the commands to run ans pin the two processes, you will only need to modify the CPU numbers based on your model.
You may find the following papers useful when it comes to designing your side-channels [1, 2, 3, 4]. We have discussed some of them during the course. In [4] a technique called "pointer chasing" is described that allows the attacker to avoid the hardware prefetching mechanisms. Specifically, instead of traversing the eviction set addresses sequentially, the attacker creates an eviction set with addresses that are randomly ordered in a simple linked list. You might want to follow this technique or its enhanced version presented in [1] for your Prime+Probe attack.
The lab is inspired by other courses from Christopher Fletcher at UIUC and Mengjia Yan at MIT. Some of the lab is adapted from their work.