Hardware bug in Skylake and Kaby Lake : Unsafe Hyper-Threading

[mariushm]

According to Debian mailing list, 6th and 7th generation Intel processors have some hardware bug that makes hyperthreading unsafe.

Users should disable hyperthreading until Intel comes with a microcode update.

 

Link: https://lists.debian.org/debian-devel/2017/06/msg00308.html

 

Pasting the message for convenience :

 

Quote

This warning advisory is relevant for users of systems with the Intel
processors code-named "Skylake" and "Kaby Lake".  These are: the 6th and
7th generation Intel Core processors (desktop, embedded, mobile and
HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
well as select Intel Pentium processor models.

TL;DR: unfixed Skylake and Kaby Lake processors could, in some
situations, dangerously misbehave when hyper-threading is enabled.
Disable hyper-threading immediately in BIOS/UEFI to work around the
problem.  Read this advisory for instructions about an Intel-provided
fix.


SO, WHAT IS THIS ALL ABOUT?
---------------------------

This advisory is about a processor/microcode defect recently identified
on Intel Skylake and Intel Kaby Lake processors with hyper-threading
enabled.  This defect can, when triggered, cause unpredictable system
behavior: it could cause spurious errors, such as application and system
misbehavior, data corruption, and data loss.

It was brought to the attention of the Debian project that this defect
is known to directly affect some Debian stable users (refer to the end
of this advisory for details), thus this advisory.

Please note that the defect can potentially affect any operating system
(it is not restricted to Debian, and it is not restricted to Linux-based
systems).  It can be either avoided (by disabling hyper-threading), or
fixed (by updating the processor microcode).

Due to the difficult detection of potentially affected software, and the
unpredictable nature of the defect, all users of the affected Intel
processors are strongly urged to take action as recommended by this
advisory.


DO I HAVE AN INTEL SKYLAKE OR KABY LAKE PROCESSOR WITH HYPER-THREADING?
-----------------------------------------------------------------------

The earliest of these Intel processor models were launched in September
2015.  If your processor is older than that, it will not be an Skylake
or Kaby Lake processor and you can just ignore this advisory.

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):

    grep name /proc/cpuinfo | sort -u

Once you know your processor model name, you can check the two lists
below:

  * List of Intel processors code-named "Skylake":
    http://ark.intel.com/products/codename/37572/Skylake

  * List of Intel processors code-named "Kaby Lake":
    http://ark.intel.com/products/codename/82879/Kaby-Lake

Some of the processors in these two lists are not affected because they
lack hyper-threading support.  Run the command below in a command line
shell (e.g. xterm), and it will output a message if hyper-threading is
supported/enabled:

  grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && \
	echo "Hyper-threading is supported"

Alternatively, use the processor lists above to go to that processor's
information page, and the information on hyper-threading will be there.

If your processor does not support hyper-threading, you can ignore this
advisory.


WHAT SHOULD I DO IF I DO HAVE SUCH PROCESSORS?
----------------------------------------------

Kaby Lake:

Users of systems with Intel Kaby Lake processors should immediately
*disable* hyper-threading in the BIOS/UEFI configuration.  Please
consult your computer/motherboard's manual for instructions, or maybe
contact your system vendor's support line.

The Kaby Lake microcode updates that fix this issue are currently only
available to system vendors, so you will need a BIOS/UEFI update to get
it.  Contact your system vendor: if you are lucky, such a BIOS/UEFI
update might already be available, or undergoing beta testing.

You want your system vendor to provide a BIOS/UEFI update that fixes
"Intel processor errata KBL095, KBW095 or the similar one for my Kaby
Lake processor".

We strongly recommend that you should not re-enable hyper-threading
until you install a BIOS/UEFI update with this fix.


Skylake:

Users of systems with Intel Skylake processors may have two choices:

1. If your processor model (listed in /proc/cpuinfo) is 78 or 94, and
   the stepping is 3, install the non-free "intel-microcode" package
   with base version 3.20170511.1, and reboot the system.  THIS IS
   THE RECOMMENDED SOLUTION FOR THESE SYSTEMS, AS IT FIXES OTHER
   PROCESSOR ISSUES AS WELL.

   Run this command in a command line shell (e.g. xterm) to know the
   model numbers and steppings of your processor.  All processors must
   be either model 78 or 94, and stepping 3, for the intel-microcode fix
   to work:

         grep -E 'model|stepping' /proc/cpuinfo | sort -u

   If you get any lines with a model number that is neither 78 or 94, or
   the stepping is not 3, you will have to disable hyper-threading as
   described on choice 2, below.

   Refer to the section "INSTALLING THE MICROCODE UPDATES FROM NON-FREE"
   for instructions on how to install the intel-microcode package.

2. For other processor models, disable hyper-threading in BIOS/UEFI
   configuration.  Please consult your computer/motherboard's manual for
   instructions on how to do this.  Contact your system vendor for a
   BIOS/UEFI update that fixes "Intel erratum SKW144, SKL150, SKX150,
   SKZ7, or the similar one for my Skylake processor".

NOTE: If you did not have the intel-microcode package installed on your
Skylake system before, it is best if you check for (and install) any
BIOS/UEFI updates *first*.  Read the wiki page mentioned below.


INSTALLING THE MICROCODE UPDATES FROM NON-FREE:
-----------------------------------------------

Instructions are available at:

    https://wiki.debian.org/Microcode

Updated intel-microcode packages are already available in non-free for:
unstable, testing, Debian 9 "stretch" (stable), and Debian 8 *backports*
(jessie-backports).

THE MICROCODE PACKAGES FROM THE RECENT STABLE RELEASE (June 17th, 2017)
ALREADY HAVE THE SKYLAKE FIX, BUT YOU MAY HAVE TO INSTALL THEM.

Updated intel-microcode packages in non-free for Debian 8 "jessie"
(oldstable) are waiting for approval and will likely be released in the
next non-free oldstable point release.  They are the same as the
packages in non-free jessie-backports, with a change to the version
number.

The wiki page above has instructions on how to enable "contrib" and
"non-free", so as to be possible to install the intel-microcode package.

Users of "jessie" (oldstable) might want to enable jessie-backports to
get *this* intel-microcode update faster.  This is also explained in the
wiki page above.


MORE DETAILS ABOUT THE PROCESSOR DEFECT:
----------------------------------------

On 2017-05-29, Mark Shinwell, a core OCaml toolchain developer,
contacted the Debian developer responsible for the intel-microcode
package with key information about a Intel processor issue that could be
easily triggered by the OCaml compiler.

The issue was being investigated by the OCaml community since
2017-01-06, with reports of malfunctions going at least as far back as
Q2 2016.  It was narrowed down to Skylake with hyper-threading, which is
a strong indicative of a processor defect.  Intel was contacted about
it, but did not provide further feedback as far as we know.

Fast-forward a few months, and Mark Shinwell noticed the mention of a
possible fix for a microcode defect with unknown hit-ratio in the
intel-microcode package changelog.  He matched it to the issues the
OCaml community were observing, verified that the microcode fix indeed
solved the OCaml issue, and contacted the Debian maintainer about it.

Apparently, Intel had indeed found the issue, *documented it* (see
below) and *fixed it*.  There was no direct feedback to the OCaml
people, so they only found about it later.

The defect is described by the SKZ7/SKW144/SKL150/SKX150/KBL095/KBW095
Intel processor errata.  As described in official public Intel
documentation (processor specification updates):

  Errata:   SKZ7/SKW144/SKL150/SKX150/SKZ7/KBL095/KBW095
            Short Loops Which Use AH/BH/CH/DH Registers May Cause
            Unpredictable System Behavior.

  Problem:  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. This can only happen when both logical
	    processors on the same physical processor are active.

  Implication: Due to this erratum, the system may experience
	    unpredictable system behavior.

We do not have enough information at this time to know how much software
out there will trigger this specific defect.

One important point is that the code pattern that triggered the issue in
OCaml was present on gcc-generated code.  There were extra constraints
being placed on gcc by OCaml, which would explain why gcc apparently
rarely generates this pattern.

The reported effects of the processor defect were: compiler and
application crashes, incorrect program behavior, including incorrect
program output.


What we know about the microcode updates issued by Intel related to
these specific errata:

Fixes for processors with signatures[1] 0x406E3 and 0x506E3 are
available in the Intel public Linux microcode release 20170511.  This
will fix only Skylake processors with model 78 stepping 3, and model 94
stepping 3.  The fixed microcode for these two processor models reports
revision 0xb9/0xba, or higher.

Apparently, these errata were fixed by microcode updates issued in early
April/2017.  Based on this date range, microcode revision 0x5d/0x5e (and
higher) for Kaby Lake processors with signatures 0x806e9 and 0x906e9
*might* fix the issue.  We do not have confirmation about which
microcode revision fixes Kaby Lake at this time.

Related processor signatures and microcode revisions:
Skylake   : 0x406e3, 0x506e3 (fixed in revision 0xb9/0xba and later,
                              public fix in linux microcode 20170511)
Skylake   : 0x50654          (no information, erratum listed)
Kaby Lake : 0x806e9, 0x906e9 (defect still exists in revision 0x48,
                              fix available as a BIOS/UEFI update)


References:
https://caml.inria.fr/mantis/view.php?id=7452
http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog
https://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v6-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v5-spec-update.html
https://www.intel.com/content/www/us/en/products/processors/core/6th-gen-x-series-spec-update.html

[1] iucode_tool -S will output your processor signature.  This tool is
    available in the *contrib* repository, package "iucode-tool".

-- 
  Henrique Holschuh

 

[PeachyUwUSenpai]

has intel replied to these allegations?

[ARikozuM]

I wonder if this is a problem with gcc, unless I'm mistaking an issue with Ryzen with this one. 

[DocSwag]

Um so what do I do if I'm on windows and have skylake? Is there nothing I can do?

[79wjd]

1 minute ago, DocSwag said:

Um so what do I do if I'm on windows and have skylake? Is there nothing I can do?

Disable hyperthreading

[NumLock21]

There are other issue that no one has heard about it yet.

[DocSwag]

Just now, djdwosk97 said:

Disable hyperthreading

Screw that I'm not doing that.

 

Considering this bug has been around for ages I *probably* will be fine  

[Cool Guy]

1 minute ago, DocSwag said:

Screw that I'm not doing that.

 

Considering this bug has been around for ages I *probably* will be fine  

Maybe you just haven't used the processor enough to cause it to hyper thread to an unsafe level.  It's not like you're losing any gaming performance disabling hyper threading.  And if you're rendering and using hyper threading on a constant basis, your chance of encountering this bug is quite high I would imagine.  Your best bet would be to just disable it. 

 

It's also possible that the effects of this bug might cause a system freeze or crash, but not instant death of the processor.  Maybe just some permanent damage.  Do you want to risk your processor getting damaged (probably is already if you use hyper threading on a constant basis)?  I don't think your comment is very wise.  It's your decision.  But think it over carefully. 

[Avcn42]

Thanks again Intel

[ivan134]

19 minutes ago, Cool Guy said:

Maybe you just haven't used the processor enough to cause it to hyper thread to an unsafe level.  It's not like you're losing any gaming performance disabling hyper threading.  And if you're rendering and using hyper threading on a constant basis, your chance of encountering this bug is quite high I would imagine.  Your best bet would be to just disable it. 

 

It's also possible that the effects of this bug might cause a system freeze or crash, but not instant death of the processor.  Maybe just some permanent damage.  Do you want to risk your processor getting damaged (probably is already if you use hyper threading on a constant basis)?  I don't think your comment is very wise.  It's your decision.  But think it over carefully. 

Yes, you are. How are there still many people living under rocks that don't understand i7 are better in CPU intensive games and that games in general are becoming now hyper threaded? Better average fps, better minimums and no stuttering. And the gulf in performance between an i5 and an i7 increases the more powerful the card is.

[DocSwag]

19 minutes ago, Cool Guy said:

Maybe you just haven't used the processor enough to cause it to hyper thread to an unsafe level.  It's not like you're losing any gaming performance disabling hyper threading.  And if you're rendering and using hyper threading on a constant basis, your chance of encountering this bug is quite high I would imagine.  Your best bet would be to just disable it. 

 

It's also possible that the effects of this bug might cause a system freeze or crash, but not instant death of the processor.  Maybe just some permanent damage.  Do you want to risk your processor getting damaged (probably is already if you use hyper threading on a constant basis)?  I don't think your comment is very wise.  It's your decision.  But think it over carefully. 

As someone else said, hyper threading does impact gaming performance.

 

Stuff like data corruption and data loss wouldn't impact me, as I don't have any sensitive info stored on my pc. Not to mention it's been over a year and a half with my CPU and I haven't had issues. Which indicates the risk is SUPER LOW. And I don't see it saying it'll cause permanent damage anywhere.

[ARikozuM]

3 minutes ago, ivan134 said:

Yes, you are. How are there still many people living under rocks that don't understand i7 are better in CPU intensive games and that games in general are becoming now hyper threaded? Better average fps, better minimums and no stuttering.

HT doesn't do any calculations for the CPU. What it does is schedules calculations for lower down-time. 

[imreloadin]

So since this is a Linux bug does that mean Windows isn't affected?

[mariushm]

Downoad latest bios update for your mb, it may contain the microcode update for your cpu which fixes this issue.or just read bios notes to see if it fixes this.

 

read the note and see if your cpu is even from a series that's affected.. the serial numbers/revisions are mentioned in the quoted text

 

if some software/game crashes often, it may be due to this issue in which case go in bios and disable hyperthreading

[AresKrieger]

Well it doesn't affect me and seems to be an issue with Linux more than anything given how large the widows os user base is and the lack of issues reported there so their statement

 

Quote

Please note that the defect can potentially affect any operating system
(it is not restricted to Debian, and it is not restricted to Linux-based
systems).  It can be either avoided (by disabling hyper-threading), or
fixed (by updating the processor microcode).

holds little water due to that fact, additonally this doesn't look like a source we can verify so I'm dismissing it until proof emerges

[Arika]

[removed]

[DocSwag]

7 minutes ago, imreloadin said:

So since this is a Linux bug does that mean Windows isn't affected?

No, it's a CPU big, which means your CPU is affected, not any specific os. Which means anyone with skylake or Kaby Lake and hyperthreading is affected.

[AresKrieger]

1 minute ago, DocSwag said:

No, it's a CPU big, which means your CPU is affected, not any specific os. Which means anyone with skylake or Kaby Lake and hyperthreading is affected.

If the claim is valid, but logically it looks unlikely given how small the userbase is on Debian compared to windows it would be far more likely for this issue to arise on that platform given the volume of users

[BuckGup]

Intel isn't perfect either

[DocSwag]

1 minute ago, AresKrieger said:

If the claim is valid, but logically it looks unlikely given how small the userbase is on Debian compared to windows it would be far more likely for this issue to arise on that platform given the volume of users

It's possible that it's a universal issue, but something within Debian is more likely to trigger it.

 

This is something that is fixed with a microcode update not a software update so definitely universal, some oses just might be a lot more likely to trigger it.

[ARikozuM]

13 minutes ago, DocSwag said:

It's possible that it's a universal issue, but something within Debian is more likely to trigger it.

Linux apparently uses GCC as it's compiler which is why they're affected. Most of us Windows users have installers that do things automagically (<- not a typo). Linux users may have to compile their installs on their own. 

 

I'm a Windows 8.1/10/Linux Mint user and haven't run into this issue since I'm on Haswell, but I can see why it'd be a huge issue. 

[DocSwag]

1 minute ago, ARikozuM said:

Linux apparently uses GCC as it's compiler which is why they're affected. Most of us Windows users have installers that do things automagically (<- not a typo). Linux users may have to compile their installs on their own. 

 

I'm a Windows 8.1/10/Linux Mint user and haven't run into this issue since I'm on Haswell, but I can see why it'd be a huge issue. 

So basically, it shouldn't be a huge worry except for linux users?

 

I assume then it's something in GCC that sometimes triggers it then?

[AresKrieger]

28 minutes ago, DocSwag said:

It's possible that it's a universal issue, but something within Debian is more likely to trigger it.

 

This is something that is fixed with a microcode update not a software update so definitely universal, some oses just might be a lot more likely to trigger it.

That is also possible, frankly I'm not worried about this issue and wouldn't be even with a skylake cpu it seems like an isolated problem additionally until someone verifies it I'll treat it as false until proven true (since information is generally false online especially info without solid sources)

[ARikozuM]

4 minutes ago, DocSwag said:

I assume then it's something in GCC that sometimes triggers it then?

I'm going to have to assume so given that both Ryzen and Skylake/Kaby Lake show the symptoms. 

 

Spoiler

Unless it's all a conspiracy to destroy Linux...

Spoiler

/s

 

 

[Cool Guy]

41 minutes ago, ivan134 said:

Yes, you are. How are there still many people living under rocks that don't understand i7 are better in CPU intensive games and that games in general are becoming now hyper threaded? Better average fps, better minimums and no stuttering. And the gulf in performance between an i5 and an i7 increases the more powerful the card is.

TBH I don't care.  

37 minutes ago, DocSwag said:

As someone else said, hyper threading does impact gaming performance.

 

Stuff like data corruption and data loss wouldn't impact me, as I don't have any sensitive info stored on my pc. Not to mention it's been over a year and a half with my CPU and I haven't had issues. Which indicates the risk is SUPER LOW. And I don't see it saying it'll cause permanent damage anywhere.

Alright, not my business.  I didn't need some whole explanation.  Not trying to be rude, just not my business so tbh I don't really care. 

33 minutes ago, imreloadin said:

So since this is a Linux bug does that mean Windows isn't affected?

It's a universal bug with the Intel processor microcode.  You can be running Solaris that magically supports Intel x86 and still be vulnerable to this bug. 

24 minutes ago, AresKrieger said:

Well it doesn't affect me and seems to be an issue with Linux more than anything given how large the widows os user base is and the lack of issues reported there so their statement

 

holds little water due to that fact, additonally this doesn't look like a source we can verify so I'm dismissing it until proof emerges

I would agree with that.  I'd expect some article to be out by now using a quote from a 12 year old saying how his brand new PC died because he ran too many applications, and highlighting on Intel's bug. 

4 minutes ago, DocSwag said:

So basically, it shouldn't be a huge worry except for linux users?

 

I assume then it's something in GCC that sometimes triggers it then?

GCC can still be used on Windows.  I guess just be careful what you run, or look into it and check what C compiler they used to compile the application.  I'm not knowledgeable in this area.