Slashdot Mirror
New HyperThreading Flaw Affects Intel 6th And 7th Generation Skylake and Kaby Lake-Based Processors (hothardware.com)
MojoKid writes: A new flaw has been discovered that impacts Intel 6th and 7th Generation Skylake and Kaby Lake-based processors that support HyperThreading. The issue affects all OS types and is detailed by Intel errata documentation and points out that under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers, as well as their corresponding wider register (e.g. RAX, EAX or AX for AH), may cause unpredictable system behavior, including crashes and potential data loss. The OCaml toolchain community first began investigating processors with these malfunctions back in January and found reports stemming back to at least the first half of 2016.
The OCaml team was able pinpoint the issue to Skylake's HyperThreading implementation and notified Intel. While Intel reportedly did not respond directly, it has issued some microcode fixes since then. That's not the end of the story, however, as the microcode fixes need to be implemented into BIOS/UEFI updates as well and it is not clear at this time if all major vendors have included these changes in their latest revisions.
The OCaml team was able pinpoint the issue to Skylake's HyperThreading implementation and notified Intel. While Intel reportedly did not respond directly, it has issued some microcode fixes since then. That's not the end of the story, however, as the microcode fixes need to be implemented into BIOS/UEFI updates as well and it is not clear at this time if all major vendors have included these changes in their latest revisions.
.. doesn't mean what the article writer appears to think it means.
Anyhow, that a new highly complex processor contains subtle bug that's fixable without hardware modification isn't exactly earth-shaking news, surely? How about they just fix it, and we move on.
AMD Ryzen also seems to have a similar bug, related to hyperthreading that happens only in very special circumstances.
Quite a few Ryzen users have experienced instability problems during heavy compilation loads under Linux, especially those using compile-based distros such as Gentoo, but also under the Ubuntu subsystem on Windows.
There has been some debate whether the problems would have been caused by an actual bug, or if the people who experienced them simply had an unstable overclock - the latter being something that has also cropped up in forums recently.
Matthew Dillon, of Dragonfly BSD fame (and Amiga fame before that...) does believe that he has found a reproducible bug. He sent a test case about it to AMD in April.
This is not the first time Dillon has found a hardware bug in a AMD CPU. He found one for an earlier AMD CPU back in 2012 which was fixed in a microcode update.
I expect this to be fixed in a BIOS/microcode update soon, if not already in AGESA 1.0.0.6 - but I have yet to see any confirmation that it would have been fixed.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
The linked FA does not contain a link to the original Intel DOC:
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/6th-gen-x-series-spec-update.pdf
Unfortunately it does not contains much info...
You can often not simply install an update as a user. There is no way to do so without the BIOS vendor doing it for you.
All you losers with your over-priced Intel crap.
I've used nothing but AMD for 20 years and I have absolutely no probl%#^$^%J NJasllodofufm DUDFUF&&()()FDJJDNDMS .......
Are you complaining about the topic as being too insignificant to deserve an article (as in: no need to tell people that they way want to update their servers) or are you preemptively commenting that other readers shouldn’t bother to comment on such an insignificant topic?
Wow! I kept reading over and over trying to find how it was escalating ring level or information leak through cache etc. but couldn't find it! I reaaaaallly wasn't expecting any type of "flaw" on slashdot to not be about some dumb security mistake. Way to surprise me again, SLUSHBOT
So you acknowledge that this is fixed, that anyone can apply the fix, but your only complaint is that the update isn't 'free as in liberty'?
No, read my post again. For certain models, the microcode fix is useless. You have to neuter your CPU by disabling hyper-threading. So money spent getting this expensive tech has gone down the drain.
Jesus fucking Christ. What has happened to Slashdot?
Apparently, many readers suffer from reading comprehension problems.
It will be a cold day in hell before I buy another Intel CPU, let alone let them install microcode on my current CPU.
Seven puppies were harmed during the making of this post.
It's a bit paradoxical that it was the OCaml team who found this bug, whereas OCaml is notoriously bad at parallelism.
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Useful links:
The Intel ME subsystem can take over your machine, can't be audited
REcon 2014 - Intel Management Engine Secrets
Untrusting the CPU (33c3)
Towards (reasonably) trustworthy x86 laptops
30C3 To Protect And Infect - The militarization of the Internet
30c3: To Protect And Infect Part 2 - Mass Surveillance Tools & Software
1. Introduction, what is Intel ME
Short version, from Intel staff:
Re: What Intel CPUs lack Intel ME secondary processor?
Amy_Intel Feb 8, 2016 9:27 AM
The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current Intel chipsets, I even checked with the engineering department and they confirmed it.
Long version:
ME: Management Engine
The Intel Management Engine (ME) is a separate computing environment physically located in the MCH chip or PCH chip replacing ICH.
The ME consists of an individual processor core, code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system's memory as well as to reserve a region of protected external memory to supplement the ME's limited internal RAM. The ME also has network access with its own MAC address through the Intel Gigabit Ethernet Controller integrated in the southbridge (ICH or
There are a lot of inaccurate comments here. First of all, reloading a new BIOS/system firmware may be the best solution for most users, however it is not the only solution. If you know how you can do a hotfix load of firmware in Linux and I suspect other OSes.
For example, I downloaded the latest firmware from Intel (dated 10 May) and placed it in /lib/firmware. Then running:
echo 1 > /sys/devices/system/cpu/microcode/reload
was enough. In the log is an entry:
[2246029.695843] microcode: updated to revision 0xba, date = 2017-04-09
In addition, the article points to a message on the debian-devel (not users) mailing list. This indicates that i3/5/7 processors with hyperthreading are affected. AFAIK, no i5 processors have hyperthreading, even though the family/model/stepping on my system is indicated in the message as vulnerable.
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Well what is it? Hyperthreading or all skylake/kaby lake? Curious minds want to know.
One last thing. The current firmware package is dated May 10. Seven weeks ago, The firmware itself was produced April 9 -- 11 weeks ago. Unless Intel has not updated yet for this, many posters here are running around with their hair on fire about something already fixed.
But I guess that is normal for slashdot.
There needs to be serious penalties for companies that create poor products with serious defects. These flawed processors certainly qualify as inferior products.
You work for AMD, right? :D
AMD: The Quality Goes In Before the Name Goes On.
See earlier comment about how AMD has a very similar bug.
Sent from my TARDIS
different AC, but regardless you are wrong he is right. all of the CPU's can be fixed/updated via microcode, however for some models that haven't had publicly available fixes published you have to go to your vendor and ask them for it. that doesn't mean it requires them to do it, but they are the only ones that will currently have the updates.
Oh fuck off, Intel make billions, they should be able to test it properly if the hackers that hack it can find these flaws.
At the very minimum they could put a bounty out!
YOU obviously have no idea how to do anything but make excuses for sloppy work.
I only allow 80, 8080 & 443 in/out here
Awww, how cute.
Did it occur to you that if a hacker is able to modify the IME system, that he can direct the packets to use port numbers other than 16992-16995? 443 would be my goto port.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
...NO CARRIER ?
I never made it to chapter two. Every focus was on controlling message and image. No acknowledgement this directly affected customers, no outreach, no mitigations. Much anger at people communicating a flaw in the product, and defying Intel's response plan and schedule.
Seeing these reports of the response doesn't fix my impression.
AMD's very similar bug is suggested to only occur with over-clocking. YMMV.
Consider though that if you take Intels updated Microcode you will lose the ability to do base frequency over-clocking entirely on non-K processors whereas before using Intels update you still could on some skylake and ivy models.
So yeah... you get the chance to patch the microcode... but it may be doing things you dont want it to do...
"His name was James Damore."
Untrue. VME was broken on Ryzen at launch. Fixed with a microcode update.
for future intel chips, the microcode is expanding in size at a rapid rate as Intel adds more advanced ISA features, that's now the primary focus since there is not much to be gained from physical improvements.
Does this one get a nifty name?
There is no XUL, only WebExtensions...
Very funny