The famous speculative execution security bug

[Bulat Ziganshin]

https://www.theregister.co.uk/2018/0...u_design_flaw/

https://www.theregister.co.uk/2018/0...vulnerability/

---

https://www.kb.cert.org/vuls/id/584653

https://googleprojectzero.blogspot.r...with-side.html

---

https://meltdownattack.com/meltdown.pdf

https://spectreattack.com/spectre.pdf

https://gruss.cc/files/kaiser.pdf

[Kennon Conrad]

How does this go a decade before it is fixed?

[Bulat Ziganshin]

it's 5 decades now, since the first cpu with speculative execution was ibm 360/91. once it known, the hole looks so obvious what i wonder whether it was really unknown, or just silently exploited by ANB, FSB and the rest

[Piotr Tarsa]

Not every CPU with speculative execution ignores privilege levels when prefetching data to caches. It's a bug in CPU design, not something inherent to speculative execution.

[Alexander Rhatushnyak]

[Bulat Ziganshin]

the same bug was detected 12 years ago:
https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/

... and silently ignored

[Piotr Tarsa]

How is it the same? Does x86 instruction set contain any instruction that violate cache coherence?

[xcrh]

How is it the same? Does x86 instruction set contain any instruction that violate cache coherence?

I guess "theoretically" it shouldn't be this way. But most real-world speculative execution implementations proven to be "imperfect". When speculative execution takes place, effects of losing part are supposed to be cancelled, like if it never took place. Yet, illusion is often flawed, one way or another. It happened on many CPUs, x86s from Intel are just one example. AMD swears they aren't vulnerable to most annoying version of this problem (and it is annoying if some lame JavaScript could steal all your passwords from memory and even dump kernel memory it shouldn't be able to touch at all). Still, even AMD suffers from different, less severe but troublesome flaws. They wouldn't take such a huge performance hit Intel is going to undertake though. But it isn't the whole story. Look, high-end ARM64 ICs featuring OoO proven to be affected as well. Low end ARM64 which are in-order execution appear to be "secure". But wait, even RISC-V which is just rising got OoO related problems, lol. The only reason why there was no buzz is that nobody was fast enough to design and sell SoC boasting OoO RISV-V cores affected by bugs. In-order execution things aren't affected, FPGA prototypes would just run fixed cores once these are available, etc.But overall it seems world has wildly missed hazards of OoO deAsigns. Somehow it slipped almost unnoticed. And it took that long. If you think it's all, nope, not a chance. There was RowHammer, almost equally epic thing, targeting DRAM designs itsels. Actually, you can craft plenty of "special" patterns under SW control when HW would perform well below of what you expect. Ever heard of movie you couldn't read back from CD? Drawing certain patterns on your monitor in real time could turn it into (low power) RF transmitter, lol. There is plenty of fun with unintended side use of data, code and HW. Last but not least, the more complicated HW and SW is, the more fragile it gets. Ever heard of aircraft vulns? Nope, it isn't joke, its digital millenium. You can't expect less than that.

[Piotr Tarsa]

I've read about Meltdown and Spectre attacks. They don't rely in any way on cache coherence bugs. At the same time the article specifically says about cache coherence violations:

The xdcbt instruction was an extended prefetch instruction that fetched straight from memory to the L1 d-cache, skipping L2. This meant that memory coherency was no longer guaranteed, but hey, we’re video game programmers, we know what we’re doing, it will be fine.

Show me where in the description of Meltdown or Spectre attacks is a discussion about cache coherence violations.

Problem with Xbox 360 CPU was that there was CPU instruction that violated cache coherence explicitly and by design. It was 100% intentional and it was an performance optimization. It turned out that it caused too much pain, had created much more damage than gain, so developers stopped using it entirely. When they stopped using that instruction the problem was gone. Speculative execution worsened the problem, but it could be alleviated just like Spectre is alleviated today. The code:

if (flags & PREFETCH_EX)
  __xdcbt(src+offset);
else
  __dcbt(src+offset);

could be written using masks:

if (use_xdcbt)
// reserved_space can be prefetched safely
// if use_xdbct_mask == 0xffffffffh then the following equation reduces to (src+offset)
  __xdcbt(reserved_space + ((src-reserved_space+offset) & use_xdbct_mask));
else
  __dcbt(src+offset);

That would remove the problem as even speculative execution of xdcbt would not touch the sensitive cache line as 'use_xdbct_mask' would be 0 anyway and speculatively executed xdbct would prefetch cache line reserved for wrongly taken speculative executions.

Today we're wiser because we all read about Meltdown and Spectre attacks and their mitigations. Xbox 360 programmers didn't have that luxury so probably they have given up altogether on using problematic instruction instead of using Spectre-like mitigations.

The key ingredient to Meltdown and Spectre attack is the ability to reconstruct other process' data by observing cache latencies alone (that's the side-channel articles about M&S attacks are telling about). Without that speculative cache loads gains you nothing. You can't read other process' data directly, regardless if your CPU is vulnerable to Meltdown and Spectre attacks or not.