Are there any processors vulnerabilities other than Meltdown and Spectre?

Question

I read about the two vulnerabilities and also read about the CPU and processors' history a bit. I want to know if there are anymore of the hardware (especially those of the processors) before.

Answer 1

All CPU designs have at least some subtle design flaws. We call these "errata".

There have been some security-relevant CPU bugs. Usually "just" DOS attacks, though.

The Pentium F00F bug affected all Intel P5 microarchitectures before the B2 stepping (which fixed it). The lock cmpxchg8b eax (with a register operand, not memory, thus invalid) locks the CPU until a hard reboot, giving a DOS attack from unprivileged userspace. (Wikipedia says it fetched the illegal-instruction IDT entry using a locked bus cycle, so the system stayed locked waiting for the corresponding write that never came). It could be worked around in software by forcing the CPU to page-fault while trying to handle the exception.

That wikipedia entry compares it to the Cyrix "coma bug", on Cyrix CPUs from a similar era.

---

Intel's design and verification techniques have advanced since then: CPUs after Pentium have updateable microcode, and they simulate a gate-level software model of the CPU by throwing randomized instruction sequences at it, to catch unexpected behaviour even in weird microarchitectural states.

But bugs can still happen. Skylake needed a microcode update to disable its loop buffer after it turned out that AH-merging uops weren't always handled correctly with hyperthreading enabled, leading to unexpected crashes when running code generated by the OCaml compiler (erratum SKL150). (My understanding is that Coffee Lake has a working loop buffer, but SKL and KBL only run from the uop cache even for tight loops.) I think this would at best be a lockup bug; too hard to get anything specific to happen to read secrets or gain privileges.

Similarly, Skylake's mfence was made extra strong in a microcode update (blocking out-of-order execution entirely, like lfence) to fix erratum SKL079. Probably you can't exploit reordering of movntdqa weakly-ordered loads from WC memory (e.g. video RAM), but it's at least possible the security / correctness of something could depend on it.

See https://www3.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf for a complete list of Skylake errata.

AMD of course publishes errata for their CPUs, too.

---

What's different about Meltdown and Spectre is that CPU architects knew CPUs worked that way, but didn't realize there was a way to exploit it. It's pretty subtle, turning secret data into microarchitectural state, then reading that microarchitectural state back into architectural state (actual values in registers on the correct path, not in the shadow of a mispredict).

For all we know, there are other nasty surprises (new classes of microarchitectural attacks) that we'll need to redesign CPUs to efficiently mitigate.

(Meltdown is very easy to cheaply mitigate with a new design, just mask under-privileged TLB+L1d hits to 0 instead of returning the actual data. This is what some CPUs already do, according to this StuffedCow blog article that tested many microarches. Spectre is very hard to do cheaply, though.)

Hyperthreading (and in general any SMT) already exposes microarchitectural timing side-channels between threads sharing a physical core. For this and other reasons, crypto algorithms are often written carefully so their performance is not data dependent. This means avoiding lookup tables that can miss in cache. Timing side-channels are a known attack, though.