Project Zero from Google
Spectre Attacks: Exploiting Speculative Execution (Graz);
My Narrow Fix
Meltdown (Evanston) Intel specific; My notes;
Another nexus (Good FAQ)
Intel Analysis of Speculative
Execution Side Channels
I find Intel’s exploit descriptions easiest to understand.
Proposed fix by Google: Retpoline: a software construct for preventing branch-target-injection8j09kk7l
Early Popular Disclosure
(Things I had to look up to understand the exploits)
BPF JIT ⬅︎
Strong and Efficient Cache Side-Channel Protection using Hardware Transactional Memory ⬅︎ Flush+Reload
Notes from the Intelpocalypse
Regarding “prefetcher” I quote from Intel® 64 and IA-32 Architectures Optimization Reference Manual
- Data cache unit (DCU) prefetcher. This prefetcher, also known as the streaming prefetcher, is triggered by an ascending access to very recently loaded data.
The processor assumes that this access is part of a streaming algorithm and automatically fetches the next line.
- Instruction pointer (IP)-based stride prefetcher. This prefetcher keeps track of individual load instructions.
If a load instruction is detected to have a regular stride, then a prefetch is sent to the next address which is the sum of the current address and the stride.
This prefetcher can prefetch forward or backward and can detect strides of up to 2K bytes.
Mark cache lines that were speculatively loaded. (TLB entries too)
Free them upon speculation failure.
Sometimes this would actually speed things up.
Orthogonal partial fix:
Make some (all?) of the instructions whose semantics is about cache lines contingent on a bit that only the kernel can set.
Architecturally these instructions are all noops.
Without the bit set, they are really noops.
Only those rare programs with legitimate need for these ops can really execute them.
Also limit these ops to addresses to which the program has write access.