SoylentNews is people
SoylentNews
Arthur T Knackerbracket has found the following story:
During April and May, Intel started updating processor documentation with a new errata note, and over the weekend we learned why: Skylake and Kaby Lake silicon has a microcode bug.
The errata is described in detail on the Debian mailing list, and affects Skylake and Kaby Lake Intel Core processors (in desktop, high-end desktop, embedded and mobile platforms), Xeon v5 and v6 server processors, and some Pentium models.
The Debian advisory says affected users need to disable hyper-threading "immediately" in their BIOS or UEFI settings, because the processors can "dangerously misbehave when hyper-threading is enabled."
Symptoms can include "application and system misbehaviour, data corruption, and data loss".
Henrique de Moraes Holschuh, who authored the Debian post, notes that all operating systems, not only Linux, are subject to the bug.
Also at Tom's Hardware and Ars Technica.
(Score: 5, Interesting) by jasassin on Monday June 26 2017, @10:13PM (5 children)
They've only got a microcode fix for two Skylake processors, and all the Kabylake CPU's requires a UEFI update (good luck with that).
This is the kind of shit someone should be sued for. The fix for the rest of the affected processors is to turn of hyperthreading. Unacceptable.
I do have a question, if you install the microcode update is that something that is inserted at boot or is it installed into the CPU itself permanently like a BIOS update?
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 2, Interesting) by Anonymous Coward on Monday June 26 2017, @11:21PM
All the microcode updates involve SRAM changes in-cpu, meaning powering the system off reverts the processors to their fused microcode.
The only exception I have heard of is the OEM motherboard/cpus having an e-fused key which locks the cpu/motherboard together, but you would need to read online for more info on that. (Supposedly the motherboard will attempt to do the same to any non-K series CPU inserted into it, rendering it tied to the motherboard vendor/oem system integrator.
(Score: 1, Touché) by Anonymous Coward on Tuesday June 27 2017, @05:04AM (2 children)
they're not getting sued for this either.
(Score: 2) by jasassin on Tuesday June 27 2017, @06:38AM (1 child)
IIRC they offered replacement CPU's.
Time will tell.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @07:49AM
Correct. A class mate of mine had one of the affected CPUs.
They didn't offer replacements for the F0 0F C7 C8 bug a few years later, though.
(Score: 1, Interesting) by Anonymous Coward on Tuesday June 27 2017, @07:37AM
Microcode updates are normally stored in flash on the motherboard, alongside the BIOS. The BIOS provides new microcode to the CPU at start-up.
Linux is capable of doing a microcode update. This would happen as the init scripts run. Doing a microcode update while running a "real" operating system isn't a great idea; ideally the boot loader (typically grub) would handle it. Consider the "fun" that could happen with a microcode update that affects how a CPU interacts with other CPUs on a motherboard that has more than one CPU active.