On Wed, 03 Jan 2018, Vincent Deffontaines wrote: > It is not fixable by microcode, and requires ugly patching from the kernel > layer. Other OSes such as Microsoft are concerned as well.
Nobody but Intel knows whether it is fixable in microcode or not for a given processor family. And Intel has *NOT* published any public information about this yet, AFAIK. Take for example the LAPIC memory sinkhole issue[1], which is quite dangerous (allows for persistent, stealth ring -2 malware that is invisible to the BIOS, hypervisor and operating system). It was widely discussed, it was officialy acknowledged, and it was touted everywhere as "impossible to fix" in microcode because it was an architectural thing. Well, the LAPIC issue was not just fixable in microcode: it *was indeed fixed* by a set of microcode updates. The fixing was done silently(!), though. My best guess is that this particular set of updates could not be issued to the wide public because it *does* change an architectural behavior, and thus it is supposed to always be deployed along with a BIOS update to ensure compatibility. But it is available to vendors, and at least one vendor of corporate desktops and servers *did* deploy such firmware updates with the new microcode for systems with processors as old as the Core2 duo... Most likely, this new X86_BUG_CPU_INSECURE issue either cannot be fixed in microcode on every affected processor model (some have more hardwired paths than others) so you would still need a software-level fix anyway, or it is just too painful performance-wise to do it in the microcode. But this, too, is just speculation. Until Intel document it somewhere public, I am not assuming it is not possible to fix it with an microcode update. [1] http://www8.hp.com/us/en/intel-processor-memory-sinkhole.html -- Henrique Holschuh
