Before you can understand a single line of the parent note, you need a small toolbox. This page builds every piece of that toolbox from absolute zero. Read it top to bottom — each idea is a brick that the next one stands on.
The whole story starts with one uncomfortable fact: the CPU is fast, memory is slow.
Look at the figure. The CPU can do about 200 tiny steps (we call each a cycle) in the time it takes memory to answer one request. This is "the memory wall." If the CPU sat still every time it needed data, it would waste almost all of its life waiting.
Why the topic needs this: every trick in Spectre and Meltdown exists because the CPU refuses to sit and wait. Remove the slowness of memory and the attacks vanish.
Naively the CPU does instruction 1, then 2, then 3. But if instruction 2 is waiting 200 cycles for memory, the CPU is bored. So it peeks ahead: "Instruction 5 doesn't need that data — let me do it now while I wait."
That last sentence hides the whole vulnerability. The CPU splits its life into two stages:
Execute stage — the actual work happens here, possibly early, possibly out of order.
Retire stage — results are made "official" here, strictly in program order.
Why the topic needs this: the permission check for kernel memory happens at retire, but the data is already fetched at execute. That gap — the pink strip in the figure — is exactly where Meltdown lives.
This is the single most important distinction on the whole page. Read it twice.
The CPU makes a promise: "If I guess wrong, I will roll back the architectural state so nobody notices." Registers get restored, wrong memory writes are cancelled. The public record is clean.
The bug: it only cleans the public record. The private notebook keeps its scribbles.
Why the topic needs this: Spectre and Meltdown leak secrets by writing them into the microarchitectural notebook (cache) during a wrong guess. The rollback erases the register but not the cache line — and that surviving footprint is the leak.
That last clause — "store a copy for next time" — is a side effect. Reading a value changes the cache. And the change is measurable, because a later read of the same value is now fast.
Why the topic needs this: the cache is the leak channel. Fast = "this value was touched", slow = "it wasn't". That two-way answer is the whole side channel.
If Δt is small the data was cached (hit); if large it came from RAM (miss). Compare Δt against a threshold — a middle value, say 100 cycles — to decide hit vs. miss.
Why the topic needs this: the cache holds the footprint, but you still need a ruler to read it. rdtsc is that ruler.
Here is the crunch: deciding which way a branch goes may itself require slow data (was size in memory?). The CPU cannot afford to wait. So it guesses using Branch Prediction — a little machine that remembers "last few times, this branch went this way, so probably again."
Why the topic needs this: Spectre lies to the predictor. Train it to expect "taken", then feed a case that should be "not taken" — the CPU speculatively runs the forbidden path before discovering its mistake. Meltdown similarly relies on an if (0) that the predictor is tricked into entering.
Speculation = out-of-order execution (§2) guided by branch prediction (§6), leaving footprints in the cache (§4) that a timer (§5) can read after the architectural rollback (§3) tried to hide everything.
Why the topic needs this: Meltdown reads a kernel byte during the execute–retire gap, stashes it in the cache, and only then takes the page fault. The rollback undoes the register but the cache footprint survives.
Read it top-down: the speed gap forces out-of-order and caching; those plus branch prediction give speculation; speculation plus the cache-timing channel plus the retire-time fault, all riding on the architectural/microarchitectural split, produce the attacks.
Test yourself — reveal only after you have answered aloud.
What is a cycle and roughly how many cycles does a RAM access cost?
One tick of the CPU clock (~1 ns); a RAM access costs ~200 cycles vs. ~4 ns for a cache hit.
What is the difference between the execute stage and the retire stage?
Execute does the actual work early and possibly out of order; retire makes results official in strict program order and is where permission checks and faults land.
State the architectural vs. microarchitectural distinction in one line.
Architectural = registers + memory the program may see (rolled back on misspeculation); microarchitectural = cache, predictors, TLB (hidden, not rolled back).
Why does reading a value from memory change the cache, and why does that matter?
A miss stores a copy for next time, so a later access is fast — that fast/slow difference leaks which value was touched.
What does clflush do and why does an attacker use it?
Evicts a cache line so the next access is guaranteed slow, resetting the cache to a known "cold" baseline before an attack.
How does rdtsc recover a secret from the cache?
It times each candidate access; the one that comes back fast (below threshold) reveals the byte value that was speculatively touched.
What is branch training and misprediction?
Training forms a predictor habit by repeating a path; misprediction is when the CPU follows that habit but reality differs, so it speculatively ran the wrong path.
Why is the speculation window widened by flushing the condition's data?
A cache-missed condition takes longer to compute, so the CPU speculates for more cycles before catching its wrong guess.
What is a page fault and at which stage is it delivered?
An exception aborting a forbidden memory access, delivered at retire — after execute may have already cached the forbidden byte.
Why does SMT/hyperthreading matter for these attacks?
Two threads share a core's cache and predictors, so one thread can observe another's microarchitectural footprints across a trust boundary.
