How I Built a Framework to Detect Cache Side-Channel Attacks

The gap between understanding a cache attack from a paper and detecting it in running code is where the real engineering lives.

I understood the attack. Then I tried to detect it.

Reading about FLUSH+RELOAD in a paper is one thing. Building something that can actually recognize it happening on a live system is something else entirely.

The paper gives you the mechanism: shared memory, cache state, timing difference, inference. But a paper doesn't tell you what happens when the operating system schedules a background process in the middle of your measurement window. It doesn't tell you that hardware performance counters don't come with labels saying "this is an attack." It doesn't tell you that normal applications - databases, compilers, browsers - can produce cache behavior that looks suspiciously like an attack if you only look at the raw numbers.

That gap between the clean mental model and the messy reality is where RADAR was born.

RADAR (Real-time, Adaptive and Robust Detection of Cache Attacks) is a framework I built during my M.Tech research to detect cache side-channel attacks at runtime using hardware performance counters. This article is about what it took to turn a research idea into a working detection pipeline, and what that process taught me about the difference between academic evaluation and engineering a system that has to operate in the real world.

Why detecting cache attacks at runtime is hard

Cache side-channel attacks don't leave obvious traces. They don't crash programs. They don't trigger antivirus signatures. They don't write to disk or open network connections. They exploit the fact that the processor's performance optimizations - caches, speculative execution, out-of-order execution - create measurable timing differences when shared resources are accessed.

"The attacker doesn't need to read the secret. They only need to measure the side effect."

In my previous article, I explained how FLUSH+RELOAD works: the attacker flushes a shared cache line, waits for the victim to potentially access it, then reloads and measures the time.

Fast reload means the victim accessed it. Slow reload means they didn't. Repeat enough times, and you recover the secret.

But detecting this pattern at runtime is a different problem. You don't have the luxury of controlling the victim & attacker. You have a live system running unknown workloads. You have hardware counters that give you raw event counts - not labeled attack signatures. You have noise from every other process on the machine. And you have to decide, in real time, whether what you're seeing is an attack or just a database doing its job.

The simple mental model: what the framework watches and why

At the conceptual level, RADAR watches the microarchitectural footprint of cache activity.

CPU execution
      │
      ▼
┌────────────────┐
│ Cache activity │
└───────┬────────┘
        │
        ▼
Hardware Performance Counters
        │
        ▼
Measurements over time windows
        │
        ▼
Feature extraction
        │
        ▼
ML classification

CPU execution
      │
      ▼
┌────────────────┐
│ Cache activity │
└───────┬────────┘
        │
        ▼
Hardware Performance Counters
        │
        ▼
Measurements over time windows
        │
        ▼
Feature extraction
        │
        ▼
ML classification

The processor's Hardware Performance Counters (HPCs) expose low-level events: cache references, cache misses, instructions retired, branch mispredictions. These counters don't know about attacks. They only know about hardware events. But cache side-channel attacks - FLUSH+RELOAD, PRIME+PROBE, and their variants necessarily create distinctive patterns in cache activity. They cause repeated cache misses, unusual access patterns, measurable deviations from normal execution behavior. If you can capture those patterns reliably, you have a signal.

"The challenge is that the signal is buried in noise."

Technical background: performance counters as signals (brief)

Hardware performance counters are special registers built into modern processors that count specific microarchitectural events. They exist for performance profiling — developers use them to find bottlenecks, optimize cache usage, understand branch prediction behavior.

But they can also be repurposed for security monitoring.

The key insight is that a cache attack changes the statistical properties of cache-related events. A FLUSH+RELOAD attack generates a burst of cache misses on the monitored line. A PRIME+PROBE attack creates contention on specific cache sets. These changes are visible in counters like:

• LLC loads > Total last-level cache load operations
• LLC load misses > Loads that missed in the last-level cache
• Cache references > Total cache hierarchy references
• Instructions retired > Total instructions completed
• Branch misses > Branch mispredictions

By sampling these counters over fixed time windows, you get a time series of microarchitectural behavior. That time series becomes the input to the detection pipeline.

This is not a deep dive on HPCs, Article 2 covers the cache mechanics. The point here is that HPCs give you a window into cache behavior that software alone cannot provide.

The threat: cache side-channel attacks at runtime

RADAR targets cache side-channel attacks that exploit shared cache state. The primary attack variants in scope:

• FLUSH+RELOAD > Shared memory, cache line flush/reload, timing measurement
• PRIME+PROBE > Cache set priming, victim eviction, probe timing
• Variants > EVICT+RELOAD, EVICT+TIME, and other cache-contention-based techniques

These attacks share a common property: they require the attacker to repeatedly interact with the cache in ways that deviate from typical program behavior. That deviation is what RADAR tries to capture.

Detection approach: the RADAR architecture

The architecture is a pipeline, not just a classifier.

System under observation
         ↓
Hardware Performance Counters (HPC)
         ↓
Data Collection & Pre-processing
         ↓
Feature Extraction & Feature Selection
         ↓
ML-based Detection Engine
         ↓
    ┌────┴─────┐
    ↓          ↓
Benign     Attack
Activity   Detected
              ↓
       Alert / Response

System under observation
         ↓
Hardware Performance Counters (HPC)
         ↓
Data Collection & Pre-processing
         ↓
Feature Extraction & Feature Selection
         ↓
ML-based Detection Engine
         ↓
    ┌────┴─────┐
    ↓          ↓
Benign     Attack
Activity   Detected
              ↓
       Alert / Response

"The key narrative point: RADAR isn't simply an ML classifier. The interesting part is the complete pipeline around the classifier."

Data collection & pre-processing

Raw HPC readings are collected over sliding time windows. The window size is a critical parameter: too small and you lose statistical significance; too large and you lose detection latency. Pre-processing handles counter normalization, noise filtering, and alignment across multiple counters.

Feature extraction & selection

Raw counter values are transformed into features that capture the statistical properties of cache behavior: means, variances, ratios, cross-counter correlations, temporal derivatives. Feature selection then identifies which features actually carry discriminative power for cache attacks versus benign workloads. This step is crucial - not all counters are equally informative, and including irrelevant features degrades both accuracy and interpretability.

ML detection engine

The classifier takes the selected features & outputs a binary decision: benign or attack. The model choice (Random Forest, SVM, neural network, etc.) matters less than the feature quality and the training data diversity. The detection engine also produces confidence scores, enabling threshold tuning for the sensitivity/false-positive trade-off.

Alert & response

When an attack is detected with sufficient confidence, the framework can trigger alerts, log detailed forensic information, or integrate with system-level response mechanisms.

"Process isolation| Throttling | Termination"

The real engineering challenges

This is where the article shifts from architecture to the lessons that only appear when you build the system.

Challenge 1: Hardware counter data is noisy

HPCs don't directly say "a cache side-channel attack is happening." They expose low-level events - cache accesses, cache misses, instruction behavior. Those measurements are affected by:

• Normal application behavior
• Operating-system activity
• Thread scheduling
• Background processes
• Workload variations
• Hardware-specific behavior

A database doing a large scan can generate cache miss patterns that superficially resemble an attack. A compiler running optimization passes can create instruction-count bursts. The OS scheduler moving a process between cores can perturb cache state.

The engineering problem: turning _noisy low-leve_l measurements into useful detection features. This required careful window sizing, robust statistical features, and training data that captured the full range of benign system behavior - not just idle or synthetic workloads.

Challenge 2: Choosing useful counters and features

There are many available performance counters on a modern processor. Monitoring all of them is neither practical (counter multiplexing overhead) nor useful (feature dilution). The challenge: which counters actually contain enough information to distinguish benign behavior from cache attacks?

This led to a systematic process:

HPC selection → feature extraction → feature selection → classifier

We evaluated counters individually and in combination. The most consistently informative were LLC loads, LLC load misses, cache references, instructions, and branch misses. But the exact set depended on the processor generation and the attack variant. Feature selection (mutual information, recursive feature elimination, model-based importance) was essential to keep the pipeline lean and robust.

Challenge 3: Detection vs. false positives

A security detector that flags everything is useless. Normal programs can generate unusual cache behavior too — that's the fundamental tension.

RADAR has to balance three competing objectives:

Sensitivity ↔ False positives ↔ Detection latency

• High sensitivity catches more attacks but raises false alarms
• Low false positives require conservative thresholds but miss subtle attacks
• Low detection latency requires small windows but increases variance

The central theme: "The challenge wasn't simply achieving high classification accuracy. The harder problem was making the detection useful under realistic system behavior."

This meant evaluating not just on clean attack/benign datasets, but on mixed workloads where benign and attack behavior coexist. It meant measuring false positive rates under sustained normal operation, not just in controlled experiments. It meant accepting that some attacks will be missed if the cost of false alarms is too high for practical deployment.

Limitations

"Including limitations is not a weakness. It's what makes this engineering, not marketing."

Hardware dependency

HPC availability and semantics vary between processor architectures. A model/configuration developed around one CPU architecture (e.g., Intel Skylake) cannot automatically be assumed to work identically on another (e.g., AMD Zen, ARM Neoverse). Counter names, event codes, and even the existence of specific counters differ.

OS/platform dependency

The collection mechanism and permissions required to access performance counters depend on the operating system and its configuration. Linux perf, Windows ETW, and macOS kperf have different APIs, privilege requirements, and available counters. Containerization and virtualization add further complexity — HPC access from inside a container may be restricted or virtualized.

Attack coverage

RADAR is designed around cache side-channel behavior. It should not be presented as a universal intrusion-detection system capable of detecting every type of cyberattack. It does not detect network intrusions, malware, privilege escalation, or data exfiltration unless they manifest as cache contention patterns.

Workload dependency

Performance-counter behavior depends heavily on workload characteristics. A detector trained/evaluated on a limited set of workloads (e.g., SPEC CPU, synthetic benchmarks) may not generalize perfectly to completely different applications or environments (e.g., database servers, web servers, scientific computing).

The real lesson

I started this project thinking the hard part would be the machine learning. Choosing the right algorithm, tuning hyperparameters, optimizing accuracy.

I was wrong.

The hard part was the pipeline. The data collection that works reliably across reboots. The feature extraction that's fast enough for real-time operation. The training data that actually represents the diversity of benign behavior. The threshold tuning that doesn't wake up the on-call engineer at 3 AM.

"The machine learning was the smallest part of the system. The engineering around it was everything else."

That's the lesson that papers don't teach you. You learn it by building the system, running it on real hardware, watching it fail on workloads you didn't anticipate, and fixing it until it works.

And that, more than any accuracy number, is what building a detection framework actually teaches you.

Final Words…

"The framework didn't just detect cache attacks. It taught me that the distance between a research idea & a working system is measured in engineering decisions, not model architectures.