Jump to content

Skylake/Kaby Lake micro code warning !


abarbarian

Recommended Posts

There is a warning circulating G+ regarding newer intel cpu's if you have one of these cpu's you would benefit from reading the info. :breakfast:

 

I am trying to find out if my Arch has or will supply updates to the microcode via normal updates or if I need to take action.

Link to comment
Share on other sites

Well do you have one of those processors? You can easily update your microcode https://wiki.archlin...microcode Â

 

Although, you shouldn't have to it very often as they only come out once a blue moon.

 

Yup I got one of them there fancy shmancy cpu's an it is a 94/3 so I will be affected.

 

I followed the wiki when I set up and it looks like I have a "intel-ucode.img" in my EFI folder.

 

I was just a little confused as to if the new update will be included with the Arch updates as the Debian info says to do a manual update.

 

I can not follow the wikis advice to try and run iucode-tool as it will not install,

 

Verifying source file signatures with gpg...
iucode-tool_2.1.2.tar.xz ... FAILED (unknown public key FE11BFA68B158E98)
==> ERROR: One or more PGP signatures could not be verified!
:: failed to verify iucode-tool integrity

 

I am also having some slight problems with refind. The only way I can get the pc to boot at the moment is with this line in my refind_linux,conf,

 

"Boot with standard options" "ro root=/dev/nvme0n1p4"

 

I have tried several different ways to alter this line. Following advice from the forums where a similar problem was solved by this type of entry,

 

"Boot with standard options" "ro root=/dev/nvme0n1p4 initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img"

 

which seems to me to be in line with the information from the refind home page and the advice on the wiki.

However this does not work for me. I have "ro" but the wiki gives "rw" don't know if that makes a difference, and the wiki also has "quiet" which I do not have, but I do not think that they make a difference to booting.

 

So I am in a bit of a pickle. Been meaning to sort out the booting issue but got caught up with Steam and monsters in the metro :happyroll:

 

Thoughts help advice a fix would be most appreciated. :worthy:

 

Oh an I ain't swapping out refind for anything else. I done too much reading up to can it now. Plus I am a stubborn son of a ********

Edited by abarbarian
Link to comment
Share on other sites

Solved the problem of getting the gpg key. Seems the author of the program can not be bothered to construct his package properly.

 

 

 

 

I am the iucode_tool upstream author. If you cannot find my gnupg key, please try to fetch it from the keyserver network I use:

 

hkps.pool.sks-keyservers.net

 

Note that this is a hkp*S* keyserver pool, so you can (should) use TLS to connect to it.

 

There are other sks-keyservers.net keyservers, which should also have my gnupg key. Please refer to: https://sks-keyservers.net/

 

OTOH, if you problem is how to get the fetched key into the correct local keyring that Arch linux will use to validate the download, that I cannot help you with.

 

Seems a bit not right to me. :breakfast:

Link to comment
Share on other sites

securitybreach

Yeah, any time you get an error on AUR packages, always check the webpage for the package as you will mostly always find the fix in the comments.

Link to comment
Share on other sites

My bold added:

Yup I got one of them there fancy shmancy cpu's...so I will be affected.
How do you know? Have you been experiencing unexplained stability issues?

 

This is certainly not good but I note the bug has only been exposed under very remote, extreme circumstances while running benchmark programs crunching complex equations with very large numbers. In other words, in synthetic scenarios. It has not - yet - been reported to cause problems with users performing normal tasks, including games.

 

So the recommendation cited in that original Debian.org article that apparently went viral is simply wrong, IMO. They recommend disabling hyperthreading now, "just in case you run afoul of its potentially quite serious problems."

 

"Just in case"? Come on! That's putting the cart in front of the horse, IMO. If not been experiencing stability issues, there is no reason to panic and start making changes to our systems.

 

For the record, I have one of the affected Skylake processors (i5-6600) in this computer and it has been running just fine since I put it together back in February 2016. I am not going to disable hyperthreading now. I will keep an eye out for BIOS updates on my motherboard's webpage and "IF" I am experiencing problems an update addresses, then I will update my system.

  • Like 2
Link to comment
Share on other sites

My bold added:

Yup I got one of them there fancy shmancy cpu's...so I will be affected.
How do you know? Have you been experiencing unexplained stability issues?

 

This is certainly not good but I note the bug has only been exposed under very remote, extreme circumstances while running benchmark programs crunching complex equations with very large numbers. In other words, in synthetic scenarios. It has not - yet - been reported to cause problems with users performing normal tasks, including games.

 

So the recommendation cited in that original Debian.org article that apparently went viral is simply wrong, IMO. They recommend disabling hyperthreading now, "just in case you run afoul of its potentially quite serious problems."

 

"Just in case"? Come on! That's putting the cart in front of the horse, IMO. If not been experiencing stability issues, there is no reason to panic and start making changes to our systems.

 

For the record, I have one of the affected Skylake processors (i5-6600) in this computer and it has been running just fine since I put it together back in February 2016. I am not going to disable hyperthreading now. I will keep an eye out for BIOS updates on my motherboard's webpage and "IF" I am experiencing problems an update addresses, then I will update my system.

 

Well I ain't as far as I know had any problems. There have been quite a few bios updates for the mobo since I built so I will update those at some point. The mobo site shows the last microcode update as being in 2015 so they are not offering this new one but then again mobo manufactures do not always keep up to date with support.

 

I am more inclined to spend time on my boot problem which has me baffled. :breakfast:

Link to comment
Share on other sites

I think this is a smart approach. While updating the BIOS is a much more reliable and safe process than it was a few years ago, if something goes wrong (like a power outage right in the middle of the flash - been there :() a corrupt flash can still brick a motherboard. :(

  • Like 1
Link to comment
Share on other sites

Hello,

 

I don't have many devices affected by this, but the new laptop I got for myself last year had a BIOS (well, UEFI, actually) firmware update to fix this. I wold imagine other computer and motherboard manufacturers are doing the same thing?

 

Regards,

 

Aryeh Goretsky

  • Like 1
Link to comment
Share on other sites

I think this is a smart approach. While updating the BIOS is a much more reliable and safe process than it was a few years ago, if something goes wrong (like a power outage right in the middle of the flash - been there :() a corrupt flash can still brick a motherboard. :(

 

Good job my mobo has two set of bios, at least I get two goes at bricking me pc. It usually takes me two goes to get things right. :Laughing:

  • Like 2
Link to comment
Share on other sites

Good job my mobo has two set of bios
My Gigabyte does too. Though I have never had to resort to the backup/secondary BIOS, it is reassuring knowing it is there.
  • Like 1
Link to comment
Share on other sites

Good job my mobo has two set of bios
My Gigabyte does too. Though I have never had to resort to the backup/secondary BIOS, it is reassuring knowing it is there.

 

I have done bios updates on four mobos three of them form different manufacturers and had no problems. Guess I have been lucky. Mind you all of them used locally downloaded bios either from within the running os or from a usb. Maybe in the past if you were installing from the net you may have had problems with dodgy internet connections and such like.

 

:breakfast:

  • Like 3
Link to comment
Share on other sites

Over the many years, I've done 100s. Including way back in the olden days when updating the BIOS required replacing the PROM. Then to update, to actually "flashing" by erasing the EPROMs with a high intensity UV light. It was nice when EEPROMs came along. But as I noted, and as most motherboard makers note on their BIOS update pages, this is still a risky task. I never update a BIOS unless the system is on a decent UPS.

  • Like 2
Link to comment
Share on other sites

  • 3 years later...

I eventually got around to sorting my microcode glitch sorted or so I hope.

 

I floundered around for some time reading around microcode and did some fiddling along the way but felt that something was just not right with my methods.  Today I had another bash at it, funnily enough I used bash to bash away at the problem. Seems I had a "\" or a "/" in my rEFind .conf that should not have been there and now I am showing a 2019 microcode not a 2014 one.

 

Can anyone familiar with Intel microcode look at my results and tell me if my microcode is up to date.

 

JoIWQcl.png

 

😎

 

  • Like 1
Link to comment
Share on other sites

We have different cpu's, I think mine is older than yours and a different family so microcode updates will probably be different. Mine is a, Skylake i7-6700k.

 

😎

 

 

Link to comment
Share on other sites

Well I did some more digging around as I noticed that my microcode did not cover the SRBDS/Crosstalk vulnerability.

 

Here is a list of Intel cpu's affected by SRBDS,

 

Processors Affected: Special Register Buffer Data Sampling

 

I found this bug report from June 2020 for a Skylake cpu on Arch that shows there are unresolved bugs in the microcode for SRBDS.

 

https://bugs.archlinux.org/task/67011

 

and another report showing flaws in the SRBDS microcode,

 

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/36

 

and this recent 14 day old thread on Reddit which seems to suggest that there is no Arch fix yet.

 

https://www.reddit.com/r/archlinux/comments/j8ts55/srbds_vulnerable_no_microcode/

 

After even more digging on the net as the Intel site was unable to point me to microcode information, I found this list of microcode releases,

 

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases

 

This seems to indicate that there is a newer microcode, by several months , for my cpu than the one I have installed but it does not look like it has one that addresses the SRBDS bug.

 

Quote


@mcu-administrator mcu-administrator released this on 15 Nov 2019

The following files have changed in microcode-20191115 since microcode-20191113:

New Platforms

None

Updated Platforms

Processor Model Stepping Family Code Model Number Stepping Id Platform Id Old Version New Version Products
SKL-U/Y D0 6 4e 3 c0 000000d4 000000d6 Core Gen6 Mobile
SKL-U23e K1 6 4e 3 c0 000000d4 000000d6 Core Gen6 Mobile
SKL-H/S/E3 N0/R0/S0 6 5e 3 36 000000d4 000000d6 Core Gen6

 

 

I am a bit wary about installing this version of the microcode manually as microcode can cause gremlins an I have my pc running fairly well at the moment.

 

I am puzzled as to why my pc has not picked up this newer microcode. You would have thought that Arch would have got and pushed out a year old microcode.

 

Any thoughts or information welcomed here as this is proving quite a quest.

 

😎

 

Also in the Arch wiki,

 

 

Quote

 

Detecting available microcode update

It is possible to find out if the intel-ucode.img contains a microcode image for the running CPU with iucode-tool.

  1. Install intel-ucode (changing initrd is not required for detection)
  2. Install iucode-tool
  3. Load the cpuid kernel module:
    
    # modprobe cpuid

 

I did all the above and get a,
FATAL: Module cupid not found in directory /lib/modules/5.9.1-zen2-1-zen

 

Why I have no idea. 🧐

 

Link to comment
Share on other sites

1 hour ago, abarbarian said:

I did all the above and get a,

FATAL: Module cupid not found in directory /lib/modules/5.9.1-zen2-1-zen

 

Why I have no idea. 🧐

 

 

Maybe Cupid doesn't love you any more. 😆

 

Debian Buster microcode is from June, same for Sid. Surely Arch has more recent than 2019.

$ apt list --installed *microcode*
Listing... Done
intel-microcode/stable,now 3.20200616.1~deb10u1 amd64 [installed]

No srbds mitigation in current microcode:

$ grep -R . /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/srbds:Vulnerable: No microcode
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

 

Link to comment
Share on other sites

securitybreach
2 hours ago, abarbarian said:

Well I did some more digging around as I noticed that my microcode did not cover the SRBDS/Crosstalk vulnerability.

 

Here is a list of Intel cpu's affected by SRBDS,

 

Processors Affected: Special Register Buffer Data Sampling

 

I found this bug report from June 2020 for a Skylake cpu on Arch that shows there are unresolved bugs in the microcode for SRBDS.

 

https://bugs.archlinux.org/task/67011

 

and another report showing flaws in the SRBDS microcode,

 

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/36

 

and this recent 14 day old thread on Reddit which seems to suggest that there is no Arch fix yet.

 

https://www.reddit.com/r/archlinux/comments/j8ts55/srbds_vulnerable_no_microcode/

 

After even more digging on the net as the Intel site was unable to point me to microcode information, I found this list of microcode releases,

 

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases

 

This seems to indicate that there is a newer microcode, by several months , for my cpu than the one I have installed but it does not look like it has one that addresses the SRBDS bug.

 

 

I am a bit wary about installing this version of the microcode manually as microcode can cause gremlins an I have my pc running fairly well at the moment.

 

I am puzzled as to why my pc has not picked up this newer microcode. You would have thought that Arch would have got and pushed out a year old microcode.

 

Any thoughts or information welcomed here as this is proving quite a quest.

 

😎

 

Also in the Arch wiki,

 

 


I did all the above and get a,

FATAL: Module cupid not found in directory /lib/modules/5.9.1-zen2-1-zen

 

Why I have no idea. 🧐

 

 

Usually the modules not found error is because you have a newer kernel/modules installed and need to reboot to load the correct ones.

Link to comment
Share on other sites

1 hour ago, sunrat said:

Maybe Cupid doesn't love you any more.

 

Ah ha you may be right there cobber. 🙄

 

1 hour ago, securitybreach said:

 

Usually the modules not found error is because you have a newer kernel/modules installed and need to reboot to load the correct ones.

 

Same after a reboot.

 

There is a newer microcode 20200616 and it is installed on my pc but does not seem to load. Possibly my Skylake does not need it. I am still puzzled. 🤔

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...