Microarchitecture security

In Part 1, we measured the time it takes to read data from the L1 cache and from DRAM. Data in the cache was much faster to access than data in main memory. We measured a median of 28 CPU cycles for the L1 cache and 314 CPU cycles for DRAM. This difference makes cache side-channel attacks like Flush+Reload possible.

The median L1 cache latency was approximately 28 CPU cycles, while the median DRAM latency was approximately 314 CPU cycles. The difference was about 286 cycles, showing that reading data from the cache is significantly faster than reading it from main memory.

I chose a threshold of 100 CPU cycles. Any access below this threshold is considered a cache hit, while accesses above it are considered DRAM accesses. This threshold clearly separates the measured cache and DRAM latencies.

In Part 2, I set up the Flush+Reload environment, compiled the source code, resolved a linker issue in the Makefile, and successfully built the attacker program. I also ran the victim program and verified that it generated a secret flag. This lab demonstrates how cache timing can be used to infer secret information from shared memory.

The goal is to recover the secret flag by measuring cache timing differences. A cache hit indicates that the victim accessed that memory location, revealing the value of the secr