Speculative buffer overflows: attacks and defenses. (Spectre BCBS) [pdf]
people.csail.mit.edu
people.csail.mit.edu
> We also believe Spectre1.1 speculative buffer overflows are completely addressable by hardware
but Intel passes the ball over directly to OS vendors:
>Intel recommends checking with your Operating System Vendor(s) for updates or patches.
Intel HW proposals so far (CAT) do not help at all with Spectre 1.1, the here proposed SLoth and DAWG does help with Spectre 1.1 but not with Spectre 1.0. Looks like HW vendors really need to offer more HW state for all speculative branches, caches, address translations.
> All footprint attacks can be prevented by carefully partitioning microarchitectural state. For example, DAWG proposes hardware mitigations that securely partition all microarchitectural memory structures (set-associative caches, TLBs, PTE caches, etc.) to protect against both non-speculative and speculative footprint attacks. https://eprint.iacr.org/2018/418
Conveniently, a software-fix is also much, much cheaper for Intel, but it is also much, much more convenient for me to install an OS update than it is to replace CPUs in servers and desktop machines; in laptops/tablets, that might not even be possible without sending the devices to the manufacturers, which equals massive downtime.
Of course, if Intel were to release their next generation of CPUs without fixing those problems, that would make a lot of people really angry. Some interesting litigation might ensue.
I mean, morally speaking, that is exactly what they should do! But think of the pure logistics nightmare that would cause, not just to Intel themselves, but also to PC / laptop / server vendors. And last but not least, I would much rather roll out an OS update to our clients than walk around the entire company and replace CPUs.