Hector Martin

SMT is definitely evil here. Constant time may work for crypto, but it does not work for computing in general. Sure, crypto keys are high value and deserve extra protection... but that just means SMT will leak everything except your crypto keys.

If that is your concern, this is still just a drop in the bucket IMO. There are many, many side channels. But leaking data through side channels from one process to another is far from easy (even on a shared phys core, regardless of channel)... Not much worth it beyond key data.

Also, unless you're using VMs, truly malicious code on your physical core is .... a much bigger problem. And if you *are* using VMs, all the major cloud vendors have already isolated your core. All the non cloud VM stacks are on it too. L1TF makes this risk look tiny.

Containers come to mind. Also, plenty of on-premise VM stuff isn't doing proper core isolation. And in general any multiuser systems. We rely on untrusted code not escaping OS privilege boundaries all the time.

Yes, but in all of those cases is *this* even close to the most serious risk considering it is limited to info leak, high difficulty, low bandwidth, inability to target arbitrary data, etc....? Outside of very specific areas (crypto, maybe a few others) this shouldn't be a prio.

The problem with that mindset is you think you're ~safe until your not and someone comes up with a high impact exploit for your platform. The stars align and you're truly screwed.

You cannot disable all attackable surfaces though just because they may be attacked. You have to make risk- and cost-based prioritizations. That's just reality. Disabling SMT, especially because of *this* vuln, seems like a bad priority. Minimal risk avoided at v. high cost.

Anyways, we may just take very different views of either risk or cost here. Not sure this discussion is going to uncover much at this point.