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...
http://www.daemonology.net/hyperthreading-considered-harmful...
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.
Anyway, that's not the same vulnerability as any of those that have become public in the last 18 months.
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.