Question bank — Spectre - Meltdown speculative side channels

False. It undoes the architectural state (registers, committed memory) but leaves microarchitectural footprints — most importantly, cache lines the wrong path pulled in. That leftover is the whole attack surface.

False. The check is present and correct; it just happens late (at retire), while the forbidden load already ran early out-of-order and touched the cache. It's a timing/ordering flaw, not a missing check.

False. The register value is discarded when the page fault aborts the instruction. The secret is recovered indirectly by measuring which cache line the secret-indexed probe touched.

False. Meltdown breaks privilege isolation (user reads kernel across a fault). Spectre makes the victim's own trusted code speculatively misbehave via a poisoned predictor — no privilege violation is needed inside the victim.

False. The leaky instructions are the victim's legitimate array[x] load. The attacker only supplies a malicious x and pre-trains the branch, then the victim's own code leaks under misprediction.

Mostly true but useless. If the predictor could not be trained, the attacker couldn't reliably force the wrong-path speculation. But a random predictor also destroys performance, which is the entire reason Branch Prediction exists — so it's not a real option.

Partly. It reads memory mapped into the attacker's address space (classically, the kernel's direct-map of all RAM). If a region isn't mapped at all, there's no cached entry to leak — which is exactly why KPTI works.

False. Both are required. Speculation is what lets a forbidden or wrong-path load run at all; the cache side channel is the readout mechanism that survives the rollback. Remove either and the attack collapses.

False here — the attacker flushes the probe array first (clflush) so that afterward exactly one hot line stands out. A clean starting cache is the attacker's measuring instrument, not a defense.

The if(0) block never commits, but the predictor can still speculatively enter it before the condition resolves. "Dead architecturally" is not "never executed microarchitecturally."

The branch prediction is fast (~1 cycle). The window exists because computing the condition (x < array_size) is slow — e.g. array_size is a cache miss. The gap between the fast guess and the slow truth is the exploit window.

Spacing by 64 B would let neighbouring secret values land on the same line (prefetching, adjacent-line effects) and blur the readout. You space by 4096 B (a page) so each of the 256 byte-values maps to a clearly distinct line.

Retpoline doesn't make prediction correct — it removes the BTB from the loop by converting the indirect jump into a ret, steering any speculation into a harmless spin (pause; jmp) instead of an attacker-poisoned target.

KPTI changes what is mapped, not when checks run. It unmaps kernel pages from the user page tables, so the forbidden address has no valid translation to speculatively load — the secret was never reachable to cache.

They only need matching low address bits. The BTB indexes with branch_addr mod 2^n, so 0x1234 and 0xFF1234 alias to the same entry — this collision is what lets attacker training poison a victim branch.

It would kill the side channel and cripple performance by ~100×, since the entire cache hierarchy exists to hide 200 ns memory latency. Not a usable fix.

To spread each possible byte value onto its own distinct cache line/page. Without the stride, distinct secrets would collide in one line and become indistinguishable by timing.

Predictors use multi-bit history/saturating counters, so one wrong call still predicts "taken." Training biases the predictor so the single malicious call speculates down the leaky path.

Meltdown is a single specific ordering bug (permission check after out-of-order fetch), so CPUs can add the check into the speculative path. Spectre exploits speculation in general — the CPU's core optimization strategy — so there's no single line to fix.

Sibling threads on one core share microarchitectural resources (BTB, predictors, some caches). An attacker thread can poison predictor state or observe cache timing of a victim thread running simultaneously on the same core.

A cache miss on array1_size makes evaluating x < array1_size slow, widening the speculative window and giving the wrong-path load more time to complete and leave a cache footprint.

Register rollback is cheap (a few renamed entries). The cache is large, shared, and its contents are the very thing that makes the CPU fast — snapshotting/restoring it per speculation would erase all performance benefit and add huge complexity.

Indirect branches (function pointers, virtual calls, returns) don't encode their target in the instruction, so the CPU must guess the target from the BTB. That guessed target is exactly what the attacker poisons; direct branches have a fixed encoded target with far less to poison.

If there's no translation and no data anywhere in the hierarchy, the speculative load has nothing to bring into cache — so KPTI-style unmapping (not merely protecting) is what neuters the leak.

Then probe_array[0 * 4096] is the hot line. 0x00 is a perfectly valid recoverable value — but attackers often pre-flush and sometimes handle index 0 carefully because prefetchers can accidentally warm the very first line.

Likely noise or prefetching — an adjacent-line/stride prefetcher pulled in a neighbour, or a prior run left residue. Attackers repeat and take a statistical majority, and use unpredictable access order, to suppress this.

The speculative window shrinks toward zero and the leaky load may never complete before rollback — no cache footprint, no leak. This is why attackers actively slow the condition (flush array_size) to keep the window open.

Not necessarily. In-order commit is normal; the danger is out-of-order data fetch before the permission check. If the forbidden fetch reaches cache before the fault, the leak still exists.