New HyperThreading Flaw Affects Intel 6th And 7th Generation Skylake and Kaby Lake-Based Processors (hothardware.com) 135
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.
Apocryphal .... (Score:4, Insightful)
.. 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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
The fix doesn't disable hyperthreading, the fix fixes the bug.
The fix works only for some models of Skylake (models 78 and 94, stepping 3). On any other Skylakes and all Kaby Lakes there's no way other than disabling hyperthreading entirely.
A fix might or might not be released in the future, Intel doesn't say a word about the issue.
Re: (Score:1)
Eh, *all* processor models have a microcode-level fix issued. The fix does not disable HT at all. And if the fix makes anything slower, nobody noticed it. It doesn't show on a normal benchmark, either.
The people running the huge OCaml farms are not weekend computer jockeys...
It is true that just two Skylake processor *signatures* (which are for a LOT of Skylake models) have microcode in the *public* Linux distribution of microcode updates. Everyone else needs to get it through their BIOS/UEFI, that doesn
Re: (Score:3)
Uhm, nope. Only those two models have a fix issued. On everything else, you do need to disable HT, which obviously takes a massive performance hit.
Those OCaml guys merely noticed and diagnosed the problem first -- your average mouth-breathing Windows user will have a game crash, a browser corrupt a Twitter page or MS Word lose data yet again, but that's what such users are used to. Yet that their systems are already crashy doesn't mean this extra source of crashes and data corruption doesn't matter.
As fo
Re: (Score:2)
Well, yeah, it depends on your load. When you prefer individual threads to be as fast as possible even at the cost of total amount of instructions per second done, you obviously want to kill HT. On the other hand, for eg. compiles, HT is a great thing. But if you work in HPC, I don't think I need to explain the need to test your particular load.
Re: (Score:2)
They were convicted of anti-competitive behavior, the largest such conviction at the time IIRC.
Re: Apocryphal .... (Score:1)
Re: (Score:2)
Re:Apocryphal .... (Score:5, Interesting)
hyper-threading ... purportedly boosts performance by about 10-20% for multithreaded apps.
10-20% might be the case. I've also read some claims of 30% speed boost from hyperthreading. The boost is highly dependent on workload.
For me, 100% is often the case. I do a lot of tight number theoretic math loops and was astounded to find that one of my typical computations -- with little memory use and essentially no communication -- was 8 time quicker on 4 cores/8 threads compared to the single threaded version. Perfectly efficient! Your mileage will very probably vary, but it works for me.
And, FWIW, I usually prototype in oCaml :-)
Re:Apocryphal .... (Score:4, Interesting)
I looked into HT a bit, and its performance gains.
Basically, it comes down that as soon as you have real cores available that HT barely does anything and sometimes even becomes detrimental for performance. So if you have 1 core, HT shows some real benefits. With 2 cores it was pretty marginal, and with 4 cores or more you might as well disable it.
Re: (Score:2)
Re:Apocryphal .... (Score:5, Funny)
If you don't know the model name of your processor(s), the command below will tell you their model names. Run it in a command line shell (e.g. xterm): /proc/cpuinfo | sort -u
grep name
C:\>grep name /proc/cpuinfo | sort -u
'grep' is not recognized as an internal or external command, operable program or batch file.
C:\>
Re:Apocryphal .... (Score:5, Funny)
Re: (Score:1)
cat /proc/cpuinfo | grep name | sort -u
Re: (Score:1)
How about they just fix it, and we move on.
What about people on machines that haven't received bios updates in 5 years?
"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."
Re: (Score:1)
Hmm, this is only about very recent Intel processors, it is pretty much guaranteed that your system vendor can issue the update if you ask them.
If they don't, I expect sooner or later Intel will start publishing the Kaby Lake microcode fixes just like they did with Skylake, and you can fix it that way. Yes, even on Windows, although it takes some hacking.
Re: (Score:1)
"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."
Methinks it's fixed in microcode like everything else, and the article even mentions that it is. Probably written by somebody who thinks everything non-windows means BIOS.
Re: (Score:2)
A microcode patch is included with the BIOS image and is loaded by BIOS at startup. This isn't the only way to do it -- it is also possible to load a patch from the O/S. But for most users the best solution is for BIOS to do this, and that means updating the BIOS image. So the article is correct.
What’s your point, exactly? (Score:4, Funny)
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?
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
BTW, AMD has a similar bug too (Score:5, Interesting)
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 [phoronix.com]. 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.
Re:BTW, AMD has a similar bug too (Score:4, Insightful)
The difference is that Ryzen is a new architecture, where this is sort-of expected. Intel has this in an old architecture and that is just not acceptable.
Re: (Score:3)
Re: (Score:2)
You seems to be utterly clueless about how these things work. Please go away and play with LEGO or something.
Re: (Score:2)
If you are losing billions due to a CPU architecture bug then you are an idiot.
Even if you are somehow sure that the CPU has no bugs, you can't be sure it won't suffer from power glitches, cosmic rays and innumerable other things that can make it crash or get the wrong result. Not to mention the rest of the computer - ECC RAM can only correct single bit errors, assuming it has no faults.
Re: (Score:3)
> The difference is that Ryzen is a new architecture, where this is sort-of expected.
No. In the sense that this is a hardware issue, not a software issue. Hyperthread issues are not expected because the hardware is "new". Software "engineering" is a joke compared to the rigor required in hardware development. I know you may not understand this, but (successfully employed) engineers of hardware are not allowed to fuck up. Manufacturing companies spend 1000x more in design, expertise, and quality con
Re: (Score:2)
You seem to never even have heard or processor errata sheets, let alone ever read one. And you seem to be completely unaware what hardware flaws have been historically found in CPUs. As I said to the other clueless response, go please go away and play with LEGO or something.
Re: (Score:3)
Sure, lots of little things like the cpu will crash in some cases if a second level shadow of the carry flag register is set immediately after some other thing... so the fix is for the microcode to reorder the operations a little bit so that operations that target the carry flag are on the shallow side of the shadow registers... or at least never in that 2nd slot.. shit like that aint nothing
It is the parallel execution itself that isnt working here. Wrong r
Re: (Score:2)
Well, yes, to a degree. But that _is_ as expected. As CPUs are using every last trick to get faster, the whole design necessarily gets more fragile and needs longer to stabilize. This is no surprise at all. The good thing is that it looks like the current AMD design will be around for a long, long time because I think we have reached the end of large performance improvements and this was the last step. Intel may have one more fundamental re-design, but they may also not, in particular if they cannot really
Re: (Score:2)
And you seem to be completely unaware what hardware flaws have been historically found in CPUs. As I said to the other clueless response
Clueless? You're the one who equates this hypertheading bug to some other bug that may crop up once in a billion operations, and doesn't even effect the computed result.
As I said to the other clueless response, go please go away and play with LEGO or something.
I only got one response from you today. Now I know who likes using anonymous coward accounts to make personal attacks. Which I should forward to the mods, even though its unlikely they'll care.
Re: (Score:1)
Isn't one of the features of ryzen a more advanced turbo boost, why overclock?
Re: (Score:2)
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
If it only happens when you overclock, it's not a bug, it's ID10T problem.
Re: (Score:2)
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.
Re: (Score:2)
A little reminder: overclocking is the practice of running a processor with a higher clock frequency than the manufacturer guarantees* being okay. Doing that the user should always keep in mind that this can lead to errors without there being any problem with the processor and so overclocking should only be done when the result of programs aren't important.
TL;DR if the problem only occurs when overclocking then it isn't a bug.
Re: (Score:2)
Your post is a typical example of the behaviour that has hindered proper discussion on this problem.
People read half of one paragraph from one forum-post and half of a paragraph in another thread and then post a knee-jerk response to something they don't understand.
Original Intel DOC (Score:1)
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...
Re: (Score:3)
AMD: The Quality Goes In Before the Name Goes On.
See earlier comment about how AMD has a very similar bug.
Re: (Score:2)
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...
CRAZY (Score:2)
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
Cold day in hell (Score:2)
OCaml (Score:3)
Inaccurate article and comments (Score:4, Informative)
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.
Re: (Score:1)
Mobile i3 and i5s can have hyperthreading enabled.
Re: (Score:2)
Nowadays i5's tend to be quad cores without hyperthreading for desktop CPU's, and dual cores with hyperthreading for mobile CPU's. As is typical with Intel there are exceptions. Though back 6-7 years ago the most popular i5 desktop CPUs were the dual cores with hyperthreading, though even back then you could still buy quad core i5's without hyperthreading.
I've lost faith in Intel (Score:2)
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.
This probably does not bode well... (Score:2)
F00F, FDIV, and friends (Score:2)
Re: (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:2, Interesting)
Re:Zen for the win! (Score:5, Funny)
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 .......
Obligatory:Intel CPU Backdoor Report (May 5 2017) (Score:1, Insightful)
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 [youtube.com]
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag [events.ccc.de]:
"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 [github.io] using the me_cleaner [github.com] 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 [win-raid.com] 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 [ycombinator.com]
REcon 2014 - Intel Management Engine Secrets [youtube.com]
Untrusting the CPU (33c3) [youtube.com]
Towards (reasonably) trustworthy x86 laptops [youtube.com]
30C3 To Protect And Infect - The militarization of the Internet [youtube.com]
30c3: To Protect And Infect Part 2 - Mass Surveillance Tools & Software [youtube.com]
1. Introduction, what is Intel ME
Short version, from Intel staff:
Re: What Intel CPUs lack Intel ME secondary processor? [intel.com]
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 [libreboot.org]
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 PCH).
The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can't be ignored.
ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ignition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.
Quotes on Intel backdoors:
A message from RMS [fsf.org]
by Richard Stallman on Dec 29, 2016 09:45 AM
The current generation of Intel and AMD processor chips are designed with vicious back doors that users cannot shut off. (In Intel processors, it's the "management engine".)
No users should trust those processors.
2. The backdoor is next to impossible to decode and reverse engineer:
Due to multiple instruction sets + custom compression algorithm.
The Trouble With Intel's Management Engine [hackaday.com]
While most of the firmware for the ME also resides in the Flash chip used by the BIOS, the firmware isn't readily readable; some common functions are in an on-chip ROM and cannot be found by simply dumping the data from the Flash chip.
This means that if you're trying to figure out the ME, a lot of the code is seemingly missing. Adding to the problem, a lot of the code itself is compressed with either LZMA or Huffman encoding. There are multiple versions of the Intel ME, as well, all using completely different instruction sets: ARC, ARCompact, and SPARC V8. In short, it's a reverse-engineer's worst nightmare.
To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that's used in the firmware remains an unsolved problem.
But unsolved doesn't mean that people aren't working on it. There are efforts to break the ME's Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.
3. The backdoor is active even when the machine is powered off:
Intel rolled out something horrible [hackaday.com]
The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can't even look at the code.
4. Onboard ethernet and WiFi is part of the backdoor:
The ME has its own MAC and IP address for the out-of-band interface, with direct access to the Ethernet controller; one portion of the Ethernet traffic is diverted to the ME even before reaching the host's operating system
If your CPU has Intel Anti-Theft Technology enabled, it is also possible to directly access the backdoor from cell towers using 3G.
5. The backdoor uses encrypted communication:
https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Using_Intel_AMT [wikipedia.org]
AMT version 4.0 and higher can establish a secure communication tunnel between a wired PC and an IT console outside the corporate firewall. In this scheme, a management presence server (Intel calls this a "vPro-enabled gateway") authenticates the PC, opens a secure TLS tunnel between the IT console and the PC
6. Recent backdoors run Java applets
*3 billion devices run Java* and everyone's motherboard is running it.
https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#cite_ref-is_31-0 [wikipedia.org]
Starting with ME 7.1, the ARC processor can also execute signed Java applets. The ME state is stored in a partition of the SPI flash, using the Embedded Flash File System.
7. Po
Re: (Score:1)
...NO CARRIER ?
Re: (Score:2)
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
Re: (Score:1)
Yet the hackers manage it? (Score:1)
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.
Re: Need to impose penalties for poor products (Score:2)
Untrue. VME was broken on Ryzen at launch. Fixed with a microcode update.
Re: Need to impose penalties for poor products (Score:1)