Flush, wait, reload#

You can time your own memory accesses. Nothing privileged about that. What does it tell you about what somebody else’s process just did?

Step 1 — flush#

Evict one named line of memory from the cache. Not the victim’s copy: the shared copy, the one both processes are reading because the operating system mapped the same physical page into both.

Afterwards, nobody’s cache holds it.

Step 2 — wait#

Let the victim run for a fixed interval, then stop waiting.

The interval is the resolution. Too long and several accesses collapse into one observation; too short and the measurement costs more than it reads.

Step 3 — reload, and time it#

Read that same line and time the read.

Fast means something pulled it back into the cache while you waited. Slow means nothing did. One bit, per line, per interval.

The whole technique is this gap#

Two preconditions, and they are the point#

• Shared pages. The attacker has to be able to name the line it flushes — a shared library, or a hypervisor deduplicating identical pages. This is not a channel between two processes that share nothing.
• A last-level cache shared across the package. clflush reaches it, so attacker and victim need not be on the same core.

When the pages are not shared#

Turning off page deduplication is the defence most providers chose. It costs the attacker resolution, not access.

Where this course stops#

Transient-execution attacks use this same cache as their read-out channel. Their source is speculative work that never architecturally happened.

That is a different argument on different prerequisites, and this course does not teach it.

Before the Bench#

Two numbers for your own machine:

• cache line size — getconf LEVEL1_DCACHE_LINESIZE
• hit and miss latencies — your CPU vendor’s optimisation manual

The Bench classifies your own timings against that threshold, not this deck’s.