https://www.nytimes.com/2019/11/12/technology/intel-chip-fix...
No, they don't have enough microcode space for this, and the data paths in the CPU that Spectre and Meltdown affect are not programmable with microcode. The microcode updates have been hamfisted, usually amounting to a massive hammer. E.g. the first "hardware fix" for variant 2 (branch target injection) was to make the BTB not shareable across hyperthreads. The fix worked. It was to completely disable the BTB for indirect branch predictions altogether. Ha! That'll confound any sharing of it!
Intel's CPUs are completely riddled with side channels due to the way they implemented speculative rollback. They are kind of screwed.
It's worth noting that Spectre-V1 is likely to be with us for many many years. CPUs have so far only shown interest in addressing spectre when spectre is crossing process or ring boundaries. In-process spectre leaks (so variant 1, Bounds Check Bypass) are currently not really being considered a problem in the CPU's eyes. No privilege boundaries were crossed, therefore not a bug.
As in, secure in-process sandboxing seems to just be dead. Or left as an exercise for the embedding code to figure out how to in some way handle with no CPU support.
I don't really think this is a great use of transistors, and is why CPUs will probably never do it, but theoretically possible maybe.
https://www.anandtech.com/show/13450/intels-new-core-and-xeo...
I'm unsure if a "fix" is actually possible with a pure hardware solution.
If someone is on your machine and you don't know it, they don't have to use side-channel attacks.
They'll can just use any of the thousands of other ways of privilege escalation to read the super-secret information you have stored in RAM, or find it when it is written to disk.
The OpenBSD folks disabled SMT by default because of TLBleed.
A non-datacenter/cloud user disabling SMT to avoid TLBleed is like a normal person carrying a fireman's rescue saw around with them 24 hours a day in case they get into a situation they have to saw themselves out of.
If you're reading this reply, you probably automatically executed `hn.js`. Are you _sure_ you know what it does?
Unless you're browsing the web with Javascript completely disabled, and you also don't have any applications that automatically update themselves from a remote source (are you _sure_ you know what those various auto-updaters are downloading?), you're running untrusted code on your machine.
Perhaps you don't particularly care about that risk, or you don't feel the risk is severe enough to warrant the performance hit, which is fair, but the risk is there nonetheless.
After all, I'm not _SURE_ I know what it's doing.
Perhaps you don't particularly care about that risk, or you don't feel the risk is plausible enough to warrant the loss of one's computer, which is fair, but the risk is there nonetheless.
Why would a l33t haxxor waste their time on an esoteric and academic attack when they can just get their victim to click on something?
Conceptually it's also the easiest vector to mitigate in the OS--simply schedule processes in different trust domains (e.g. different UIDs) on different physical cores. This is what good VM hypervisors do. You'll never be scheduled on a physical core in parallel with another AWS tenant, which is why the minimum vCPUs on AWS is always 2. But traditional kernel schedulers (Linux, macOS, Windows, et al) and user space APIs for this mitigation are still nowhere in sight.
Here's a good paper (pre Spectre) that surveys various timing attacks and how they relate to specific architectural features: Qian Ge, Yuval Yarom, David Cock, and Gernot Heiser, "A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware", https://eprint.iacr.org/2016/613.pdf.