Comment by tntn | Hacker News Reader

Comment by tntn | Hacker News Reader

Parent Full thread

And how about the generations of computer architecture professors that have promulgated the lie that is "architecturally visible state," am I right? Speculative execution is fine, cause we just throw away the results before they become architecturally visible.

Those professors aren't doing too bad now either, with plenty of papers to be published outlining the flaws and proposing solutions.

/s

Really, though, humanity is still pretty new to this whole computer architecture thing in general, and running untrusted code securely in particular. Im skeptical that someone at Intel was aware for the possibility of vulnerabilities for 10+ years before any of them were made public.

To be honest, I'm a little perplexed by the animosity directed towards Intel after all these vulnerabilities. Vulnerabilities in software are most frequently the result of ignorance, but everyone seems to assume the engineers and managers at Intel knew better (or should have know better). Who would have told them?

It was known since the Pentium 4 era that hyper-threading had serious timing attack concerns, concerns Intel seems to have completely ignored.

http://www.daemonology.net/hyperthreading-considered-harmful...

Linux ignored those concerns as well. Torvalds didn't think hyperthreading was at fault, and Kleen stated that it was a "user space problem." In other words, there wasn't exactly consensus that there was something to fix.

Anyway, that's not the same vulnerability as any of those that have become public in the last 18 months.

Its very much in the same class of vulnerabilities, arguably its completely impossible to secure SMT, because it leaks information about what other threads are doing by the very virtue of how it works (using CPU resources the other thread isn't utilizing in a very fine grained clock-for-clock way)

> because it leaks information about what other threads are doing by the very virtue of how it works (using CPU resources the other thread isn't utilizing in a very fine grained clock-for-clock way)

The issue with MDS is not which CPU resources each thread is using. It's something much more subtle. The issue with MDS is data left over by each thread within internal temporary buffers, which shouldn't be an issue since these internal temporary buffers can't be read by the other thread before being overwritten. However, in the phantasmagoric world of Spectre, these residual values can leave an impression which can be picked up through careful manipulation.

Notably, MDS can also be exploited by the same thread. This is what the microcode updates are about: they hijack a useless legacy instruction from the 90s, adding to it the extra behavior of clearing all these internal temporary buffers. Operating systems are supposed to call this instruction whenever crossing a privilege boundary. The problem with SMT is that it's really hard to make sure both threads are on the same side of all privilege boundaries all the time.

Also note that, as far as we know, all AMD processors, even the ones with SMT, seem to be immune to MDS. This shows that this vulnerability is not a fundamental property of SMT, unlike other side channels which depend on the resource usage by each thread.

The key sentences from that paper: "If applications and libraries are written in such a manner that the code path and sequence of memory accesses are oblivious to the data and key being used, then all timing side channels are immediately and trivially closed. [We assume that the hardware used does not exhibit data-dependent instruction timings; without this assumption, it is impossible to offer any such guarantees.]"

That is, these earlier timing side channels can be avoided, even in the presence of SMT/HyperThreading, by not doing data-dependent branches or memory accesses, and not using instructions with data-dependent timings. For instance, instead of "x = cond ? a() : b();", do something like "mask = cond - 1; x = a() & ~mask | b() & mask;".

That is not the case with MDS: even if you carefully avoid data-dependent branches, memory accesses, and instruction timings, you are still vulnerable. It's really a new vulnerability class.

Reply on news.ycombinator.com