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: 0) by Anonymous Coward on Monday June 26 2017, @10:09PM (3 children)
I have Ubuntu 16.04 and my wife has Window 10. Every 1-2 days one of us has a computer f-up that can only be resolved by hard reboot. What the fuck difference does an occasional Intel-induced reboot make? Fucking computers suck my dick.
(Score: 3, Informative) by jasassin on Monday June 26 2017, @10:16PM (1 child)
Here's a nice perl script some kind soul wrote you can run on your Ubuntu system to see if it is affected:
https://lists.debian.org/debian-devel/2017/06/msg00309.html [debian.org]
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 4, Informative) by kaszz on Monday June 26 2017, @10:31PM
This seems to be the essence of it (and can be decoded manually using dmesg):
if( $vendor eq "GenuineIntel" and $family == 6) {
if ($model == 78 or $model == 94) {
if ($stepping eq "3") {
print "Your CPU is affected, ";
if (hex($microcoderev) >= 0xb9) {
print "but your microcode is new enough\n";
} elsif ($hyperthreading ne "on") {
print "but hyper threading is off, which works around the problem\n";
} else {
print "you should install the latest intel-microcode\n";
}
(Score: 2) by kaszz on Monday June 26 2017, @10:18PM
Machines with Linux could at least be expected to stay online. Seems it may be better to buy an old processor..
(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.
(Score: 4, Insightful) by kaszz on Monday June 26 2017, @10:22PM (5 children)
1994 Pentium FDIV bug [wikipedia.org]
1997 Pentium F00F bug [wikipedia.org]
2017 Intel AMT, "strncmp()"
Seems they keep up the tradition? ;)
(Score: 5, Insightful) by takyon on Monday June 26 2017, @11:03PM
Couldn't have come at a better time for AMD. Right in the middle of its struggle to regain market share. And AMD is trying to compete with Xeons as well.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 4, Interesting) by bob_super on Monday June 26 2017, @11:55PM (3 children)
> 1997 Pentium F00F bug
Stay the [bleep] away from F00F [sciencemag.org]
NSFW warning: Not sex, but it's really hard not to laugh.
(Score: 2) by LoRdTAW on Tuesday June 27 2017, @12:13AM
Thanks for that link. Not a chemistry person but I found it a very Interesting read.
(Score: 2) by Spamalope on Tuesday June 27 2017, @02:22PM (1 child)
Haha! His blog is fantastic.
One of the commenters was annoyed that every time they looked for chemical suppliers a few China based companies spammed the entire supple sites claiming they were suppliers for everything added 'weed out those guys' to the work for every search.
Someone pointed out he could just order ten pounds and solve his problem. It'd also locate the spammers, as we could find the (former) location of their lab by looking for the crater on google earth. No chance of synthesizing anywhere near that amount without something... energetic happening.
(Score: 0) by Anonymous Coward on Wednesday June 28 2017, @09:08AM
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @06:44AM
(Score: 2) by shortscreen on Tuesday June 27 2017, @09:08AM (2 children)
I guess modern compilers don't use AH,BH,CH,DH much huh? When Intel was testing out their fresh chips they must have forgot to run some vintage hand coded assembly.
(Score: 1, Informative) by Anonymous Coward on Tuesday June 27 2017, @09:40AM (1 child)
From the description, emphasis by me:
I cannot imagine any 64 bit code that doesn't use RAX, RBX, RCX or RDX, nor any 32 bit code that doesn't use EAX, EBX, ECX or EDX.
(Score: 2) by Dr Spin on Tuesday June 27 2017, @02:24PM
The way I understood this, the bug is tripped when you use the 8 bit reg in one thread and the extended reg
in another thread.
Have I read it wrong?
(I read the OpenBSD description, but on a phone, without my glasses).
I suggest that this is more evidence that a monoculture is high risk. I can't wait to see Arm servers able
to compete on performance in the "8 to 64 thread" market. It would be nice to see greater diversity in
memory interfaces too.
Warning: Opening your mouth may invalidate your brain!
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @12:56PM
for "kaby lake(gen7)" (and "skylake"(gen6)) there's a nice document from intel listing all "errata".
also the affected CPUs are listed by name (and stepping).
other then that, thanks for scaring people into sending AMD their moneys : D