For the 2024 Learning Jam I decided to learn about Spectre. I had heard about Spectre, and Spectre-type vulnerabilities for a long time but never really understood how they worked. During the jam I dove into the Spectre paper and attempted to fundamentally understand all the ingredients in a Spectre exploit.
My writeup can be found at https://bvisness.me/spectre.
Made a demo of timing attacks as part of my &spectre writeup...hopefully I still have time to actually explain the Spectre part 😅
!til working on my &spectre article this morning, plz tell me if my handwavey pipeline diagram is too handwavey
!til that &spectre is in principle possible for any kind of speculative execution, simply because if the CPU does the wrong thing, the behavior can be observed, whether by cache timing, or contention for internal CPU resources, or by monitoring power consumption...or basically anything else
!til Reducing the precision of performance.now() was a waste of time and only done to annoy me. &spectre
!til There is a conceptually simpler way of figuring out which value was read out of bounds in a &spectre attack - just index using an in-bounds value immediately afterward and see if the access is fast or slow. If it's fast, and you know the value used for the index, then you know that the secret out-of-bounds value == your index, and you've extracted the information.
!til about the BTB and RSB...so many ways for CPUs to speculate &spectre
!til There are multiple variants of &spectre described in the original paper, not just the out-of-bounds read that I've seen discussed in many places. (Also the original paper is very clear and well-written.)
!til people were extracting data via cache timing attacks back in like 2005, and yet somehow &spectre was not recognized until 2017?
