abarbarian Posted June 29, 2017 Posted June 29, 2017 Originally shared by nixCraft Affects all oses. Updated can be applied by updating your UEFI/BIOS microcode update for CPU. Make sure you apply those fixes. [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading [Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]. [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading. To: debian-user@lists.debian.org, debian-devel@lists.debian.org; Subject: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading ... lists.debian.org 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. 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. Quote
securitybreach Posted June 29, 2017 Posted June 29, 2017 Well do you have one of those processors? You can easily update your microcode https://wiki.archlinux.org/index.php/microcode Although, you shouldn't have to it very often as they only come out once a blue moon. Quote
abarbarian Posted June 29, 2017 Author Posted June 29, 2017 (edited) 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 Thoughts help advice a fix would be most appreciated. 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 June 29, 2017 by abarbarian Quote
abarbarian Posted June 29, 2017 Author Posted June 29, 2017 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. Quote
securitybreach Posted June 29, 2017 Posted June 29, 2017 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. Quote
Digerati Posted June 29, 2017 Posted June 29, 2017 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. 2 Quote
abarbarian Posted June 29, 2017 Author Posted June 29, 2017 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. Quote
Digerati Posted June 29, 2017 Posted June 29, 2017 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. 1 Quote
goretsky Posted June 30, 2017 Posted June 30, 2017 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 1 Quote
abarbarian Posted June 30, 2017 Author Posted June 30, 2017 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. 2 Quote
Digerati Posted June 30, 2017 Posted June 30, 2017 Good job my mobo has two set of biosMy Gigabyte does too. Though I have never had to resort to the backup/secondary BIOS, it is reassuring knowing it is there. 1 Quote
abarbarian Posted June 30, 2017 Author Posted June 30, 2017 Good job my mobo has two set of biosMy 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. 3 Quote
Digerati Posted June 30, 2017 Posted June 30, 2017 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. 2 Quote
abarbarian Posted October 23, 2020 Author Posted October 23, 2020 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. 1 Quote
securitybreach Posted October 23, 2020 Posted October 23, 2020 Oddly enough, my Ryzen desktop doesn't list the date: 1 Quote
abarbarian Posted October 23, 2020 Author Posted October 23, 2020 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. Quote
abarbarian Posted October 24, 2020 Author Posted October 24, 2020 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 microcode-20191115 release 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. Install intel-ucode (changing initrd is not required for detection) Install iucode-tool 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. Quote
sunrat Posted October 24, 2020 Posted October 24, 2020 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 Quote
securitybreach Posted October 24, 2020 Posted October 24, 2020 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. Quote
abarbarian Posted October 24, 2020 Author Posted October 24, 2020 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. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.