It's not resolved by, it's mitigated by.
Furthermore, it wasn't mitigated by AMD (or Intel or ARM), it was mitigated by OS / Software vendors that had to spend the time to make workarounds for the hardware's design flaw. It would have been nice to see a nod to such developers for taking the time to help with the problem.
It is easily 6 man-months of work if not double, and the level of expertise necessary to implement this right is pretty high. For a small OS shop, that's a pretty high price.
Free Software projects don't necessarily work like this. It's possible for CPU manufacturers to have taken the lead in the work in Linux, for example. Even just helping (which they have clearly done) is more of a nod than just a nod.
AMD does not even mention Intel or ARM. While Intel did. Why is that? AMD mentions it's an issue with speculative execution used in modern processor architectures. Clean and simple, and to the point.
Here's Intel's response compare: https://newsroom.intel.com/news/intel-responds-to-security-r...
Ummm none of these things will stop this attack.
EDIT : I don't even think we know of a way to fix Spectre in the kernel...
At least with Intel, I could grab a server-class motherboard and guarantee rock-solid feature implementation - with the selection of AMD motherboards available we have even separate yet contradictory settings exposed in the BIOS setup. Pathetic.
Unsupported hardware is hardly a bug.
* power status after ac power loss
* SATA ahci mode enabled
* DDR speed
* advanced ram timings
* enables NICs
* cpu overvoltage enabled
* iommu enabled status
And others I’m forgetting.
X399 IOMMU support is completely broken, as well as ASPM. These options must be disabled to even successfully install Windows 10.
The X399 Taichi bios shows me tons of options for hardware/controllers that aren’t even physically present.
These motherboards cannot run RAM at the rates speeds due to the infinity fabric design. Look at the compatibility list AsRock published. They cannot achieve 2666MHz without jumping up to ram rates for 3200MHz, if I recall correctly. That’s because X399 is built as two separate sockets that happen to share a heatspreader and lga connection, and the interconnect operates at the same speed as the ddr bus; it just can’t keep up with tight timings.
After updating to Firmware v2, 4/5 Times the bios says “no connection” when trying to check for online updates (despite the wired connection in both ports plus a 10gbe pcie card), and a full power cycle is needed to try again.
This is the first chipset I’ve seen that won’t let me run a stick of ram at a slower speed (but it let me run other ram at slower speeds, so I’m not sure why) and fails to post if I set my ram to less than the XMP 2 setting manually.
The bios is built for gamers and overclockers. The options to enable OC are “auto” or “manual” and there is no “stock” or “disabled” option.
This wasn’t a platform built for stability. Motherboard manufacturers are treating ThreadRipper as if it were Ryzen, as if we were all gamers and this wasn’t a workstation chipset.
Intel lets you run Core i7 on its server boards. AMD won’t let me use a motherboard sold for Epyc with my ThreadRipper CPU. Nor should they have to.. except my current options are all crap.
My biggest problem of all is that X399 (not just the Taichi) randomly stops recognizing certain PCI-E cards. My PCI-E 10gbe x520-da2 NIC worked ok for a couple of weeks hen suddenly wasn’t seen any more. I thought it was the card and bought a new one. Same problem. I thought it was the os so I installed another. Same problem. I thought it was the bios so I reset it. Same problem. I manually toggled each option pertaining to PCI in the bios and rebooted to test between each one. Same problem.
Took a look on NewEgg. All the x399 boards have 3 star reviews at best, and are filled with similar PCI-E complaints and “worked for a month then stopped working” across all the manufacturers and models. Which isn’t saying much, since there are only a dozen or so, really.
Notably, the exclusivity-kickback agreements they arranged with several PC manufacturers. https://www.nytimes.com/2017/09/06/business/intel-eu-antitru...
As well as making their compiler choose the slowest execution path possible once it identifies it's running on an AMD/non-Intel CPU.
Not unless you update every piece of code running on your machine to insert an lfence following every branch on attacker-controlled data.
This update makes the kernel insert fences into places where it wouldn't have been necessary before, leading to potentially severe slowdowns.
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.