In the landscape of modern computing, security concerns extend beyond operating system (OS) vulnerabilities and software bugs. Deep beneath the abstractions, our processors have evolved intricate microarchitectures—pipelines, caches, buffers, and execution engines—designed to extract maximum performance. Ironically, these features introduce new and subtle security risks, giving rise to what are known as microarchitectural attacks. Such attacks exploit the unintended sharing—and leakage—of microarchitectural state between concurrently executing applications, sometimes even in perfectly secure software.
This comprehensive blog post aims to demystify microarchitectural attacks, covering:
Whether you are a beginner, researcher, software developer, or cybersecurity professional, this guide will equip you to understand these powerful modern attacks—and how to defend against them.
Microarchitectural attacks are exploitation techniques that take advantage of unintended information leaks in the low-level design of a processor's hardware.
Unlike typical software exploits, microarchitectural attacks do not require programming bugs in the application or OS. Instead, they exploit how modern CPUs attempt to maximize performance, such as by sharing caches or reordering instructions.
Modern CPUs share critical hardware structures among applications and even virtual machines, such as:
Because these structures are not perfectly isolated, one process can often observe or infer the effects of another. Attackers exploit this implicit sharing to extract secrets by observing indirect physical effects (like slight changes in memory access time).
There are two broad categories:
Covert channels create a communication pathway between two actors (sender and receiver) not intended by the system’s design. One application modulates some shared resource, while another observes these modifications to reconstruct a message.
Examples:
Side-channel attacks leak sensitive information without direct communication. Rather, they exploit information “spilled” by the victim’s activity.
Examples:
Both channels allow one process to deduce information about another—sometimes across container, VM, or user boundaries.
Heterogeneous computing systems comprise multiple processor types (general-purpose CPUs, GPUs, FPGAs, AI accelerators, etc.) in the same platform, often sharing some memory and/or microarchitectural state.
Suppose a GPU and CPU share a cache region. A low-privileged process running on the GPU could “prime” the cache, and a high-privileged process running on the CPU could unknowingly reveal secrets through its memory accesses. Then, the low-privileged process could observe changes, inferring protected information.
RISC-V is an open-source, modular instruction set architecture, quickly gaining popularity for research and commercial embedded systems. While microarchitectural attacks are well-studied on x86 and ARM, recent research shows that RISC-V is equally susceptible.
Key Takeaway: No instruction set or open-source hardware is immune—all CPUs with shared microarchitecture are vulnerable unless specifically hardened.
A novel area: stack engine attacks (Source)
If attacker and victim share a CPU, by performing tailored stack operations and observing the resulting timing, the attacker can infer what kind of stack activity the victim recently performed.
Spectre and Meltdown (2018) made the world understand that microarchitectural attacks are more than theory—they affect billions of computers.
[Victim Process] [Attacker Process]
Executes instruction Primes cache, times accesses
on secret data Decodes changes due to victim's activity
---[Physically share cache]---
Prime+Probe is a classic attack that works as follows:
Like placing coins on all seats in a theater (prime), having someone else walk in (victim), and then checking which seats are empty (probe)—revealing where the victim sat, without directly observing them.
Recent attacks target the stack engine optimization:
It's important to emphasize: practical attacks on production systems are illegal without consent. However, performance measurements that reveal timing side channels can be performed on your own test machines for research and defense.
Simple timing probe to check for cache sharing (e.g., in virtual machines).
#!/bin/bash
buffer=/tmp/testmem
size=1024000
# Allocate a large buffer
dd if=/dev/urandom of="$buffer" bs=1K count=1000
# Repeatedly access memory to "prime" cache
function prime_cache {
for i in $(seq 1 $size); do
tail -c +$i "$buffer" | head -c 1 >/dev/null
done
}
# Time an access
function time_access {
/usr/bin/time -f "%e" dd if="$buffer" of=/dev/null bs=1K count=1000 2>&1
}
echo "Priming cache..."
prime_cache
echo "Timing read access..."
time_access
# Now ask another process to run a memory-intensive workload and repeat
# Compare to see if timing changes, indicating cache contention!
Interpret significant changes as evidence of cache contention with other processes—potentially enabling Prime+Probe attacks.
A more precise method uses Python's time module and numpy arrays for repetitive memory access patterns.
import numpy as np
import time
# Allocate a large array
arr = np.zeros((1024 * 1024 * 10,), dtype=np.uint8)
def probe_access():
ts = time.time()
# Access all elements to force cache loading
for i in range(0, len(arr), 64):
arr[i] += 1
te = time.time()
print(f"Access time: {te - ts:.6f} seconds")
# First run: should be cold (may page fault)
probe_access()
# Second run: cache likely hot
probe_access()
Now, in a second terminal (or separate process), run a memory hog script (e.g., stress-ng or similar), which will evict cache lines. Run probe_access() again and observe the time increase.
If you see larger access times after another process runs, this means your system's cache is susceptible to timing attacks.
Given the persistence of microarchitectural attacks, what can security defenders do?
# Check flush-related CPU features
grep . /proc/cpuinfo | grep -E 'flush|clflush|clwb'
# Might show: clflush, indicating available instructions for software to clear caches
Many CPU vendors are introducing features such as:
However, most deployed CPUs are still susceptible, especially in cloud environments or with complex hardware.
Microarchitectural attacks are no longer a "theoretical curiosity." As our processors become more optimized—and more shared—the subtleties of their internal designs become powerful tools in the hands of skilled attackers.
Especially in heterogeneous systems, where CPUs, GPUs, and accelerators share microarchitectural state, covert and side channels are not just possible—they are commonplace. Recent attacks against RISC-V CPUs and the stack engine demonstrate the universality and persistent relevance of these risks, even for new architectures and optimizations.
Stay current, test your own environments, and demand better isolation—in both software and hardware.
This post is for educational purposes only. Always test in safe, controlled environments.
If you found this content valuable, imagine what you could achieve with our comprehensive 47-week elite training program. Join 1,200+ students who've transformed their careers with Unit 8200 techniques.