Intel microcode bug?

Is this real? If so, when will ASRock be updating the Bios?
https://www.theregister.co.uk/2017/06/25/intel_skylake_kaby_lake_microcode_bug/

James7679-US wrote: Is this real? If so, when will ASRock be updating the Bios? https://www.theregister.co.uk/2017/06/25/intel_skylake_kaby_lake_microcode_bug/

Good question if this is real. It seems be, but this is the first news article about this that I have seen.

Obviously it will take some time before this situation is sorted out, and Intel responds to it.

This apparent issue only affects Intel Skylake and Kaby Lake processors that have Hyper Threading.

I have a Kaby Lake PC with according to the article, an affected processor. I have not experienced any failures on this PC, or had any problems with data corruption or loss that I am aware of.

I'm not saying that indicates there isn't an issue here, it happens only in certain situations according to Intel's statement in their document. I may not have encountered that situation.

When will ASRock be updating the UEFI/BIOS used in boards that can use the affected processors? If and when Intel provides a processor microcode update to mother board manufactures that fixes the issue, and it is tested and verified by the mother board manufactures. Intel is the only one that can provide any processor microcode updates for their processors. It seems the microcode update for Skylake processors exists now, but was just released in June. At this time, no one can say if or when any UEFI/BIOS updates will happen.

Microcode wrote: Thanks for starting the post! :)  Yeah it's real. Intel even already fixed the bug with a new microcode update. Now it's ASRock's turn to get it implemented into a new BIOS version.  A few of many sources:  https://hothardware.com/news/critical-flaw-in-intel-skylake-and-kaby-lake-hyperthreading-discovered-requiring-bios-microcode-fix https://lists.debian.org/debian-devel/2017/06/msg00308.html https://www.reddit.com/r/linux/comments/6jepx3/intel_skylakekaby_lake_processors_broken/ I am for instance running an i7-6700k Skylake a CPU which is affected. My ASRock board Z170 Extreme7+ runs the newest firmware 7.40 from 5/22/2017 and the current microcode version is 74. This microcode version is from last year and doesn't include the newest fix.   The source from above writes: "...Users should look for a BIOS/UEFI update which fixes ? Intel erratum SKW144, SKL150, SKX150, SKZ7" for both Skylake and Kaby Lake processors." Another source says that Skylake microcode revisions from 0xb9/0xba upwards fix the bug. So I'm hoping that there will be a new firmware 7.50 for the Z170 Extreme 7+ board in the near future :) Otherwise the only "fix" is to turn off hyper-threading in BIOS which is one of the main features of this i7 processor. Meanwhile I'll contact AsRock support and ask if they have any news.

Your statement that Intel has already fixed this bug is false, at least in the way that you worded it.

Check the underlined portion of the Debian email below for the details about the extent of the fix.

To say that it has been fixed in all affected models of both Skylake and Kaby Lake processors is not correct.

All the stories on the Internet are sourced from the original Debian users mailing list, which references the Intel Specification Update document with the errata item about this issue.

We really must read the Debian email for the details, as the other stories are little more than overviews of the Debian email, none are original reporting. Details about microcode versions from the Debian email:

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)

The Skylake microcode fix seems to have been released in April of 2017, for processor models 78 and 94, both stepping 3.

The question is would this Skylake microcode fix version be compatible with Kaby Lake processors? Not to fix the issue in Kaby Lake processors, but just be compatible with Kaby Lake processors in general.

Intel 100 series Skylake chipset boards like a Z170, now have Kaby Lake compatible UEFI/BIOS versions, starting with versions 7.20 and 7.30. Both Skylake and Kaby Lake processors can be used in these boards with those UEFI versions. The Debian email states it is unsure which microcode update, if any, fixes it for Kaby Lake.

The lack of a UEFI/BIOS update for ASRock Skylake and Kaby Lake chipset boards could be explained by two things. The lack of an overall Kaby Lake microcode fix, and the problem with providing a fix that only works for Skylake processors, and is not compatible with Kaby Lake processors.

I highly doubt any mother board manufacture will provide for general download a UEFI version for these boards that takes them back to only supporting Skylake processors, if that would be the case. We know that some Kaby Lake users would apply the Skylake only compatible update, resulting in a non-functioning PC. Even as a Beta version that would not happen, too dangerous. Possibly only on a one to one basis would a UEFI/BIOS version like this would be given to users that request it. That still risks someone posting it for general download.

Unfortunately, too many unanswered questions about this remain at this point. The good news is this issue can be fixed with microcode updates.

I just had to be clear about what is available at this point and the reason the fix may not be available yet. Simply to prevent any misunderstandings about why the microcode update has not been made available yet. Plus what is even available at this point for the microcode update is not clear.

I did not disable hyper threading since I have never had any problems with my Z270/i7-7700K PC. I have used multiple Windows 10 installations on multiple types of drives, and all is well.

The way the Debian community noticed the issue is when they were compiling the Debian source code for a Debian installation. That is something Windows users never do. So the circumstances of CPU instructions that cause the problem is never encountered by most users. It only happens during a very specific situation fortunately.

If you are a code developer that compiles programs on your PC, then I would suggest disabling hyper threading. But if you've never encountered any strange problems when doing specific tasks, then you should be fine. You can always try disabling it to see if it makes a difference in your personal usage.