Created attachment 1702449 [details] Processor Information Description of problem: The latest microcode update to Intel processor i5-6200U does not protect against the CROSSTalk vulnerabilty. https://www.vusec.net/projects/crosstalk/ The problem still exists even though it is suppose to be fixed: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T5OUM24ZC43G4IDT3JUCIHJTSDXJSK6Y Version-Release number of selected component (if applicable): 2.1-39.fc32.x86_64 How reproducible: Always, on all systems having the Intel i5-6200U processor. Steps to Reproduce: 1. Grab the latest OS updates via sudo dnf update or Gnome Software 2. Download the Meltdown OVH script via: wget https://meltdown.ovh -O spectre-meltdown-checker.sh 3. Run the script as sudo. Actual results: CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)' * Mitigated according to the /sys interface: NO (Vulnerable: No microcode) * SRBDS mitigation control is supported by the kernel: YES (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation) * SRBDS mitigation control is enabled and active: NO > STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability) Expected results: The CPU should not be vulnerable after microcode update. As it was promised. Additional info: OS Info: NAME=Fedora VERSION="32 (Workstation Edition)" ID=fedora VERSION_ID=32 VERSION_CODENAME="" PLATFORM_ID="platform:f32" PRETTY_NAME="Fedora 32 (Workstation Edition)" ANSI_COLOR="0;34" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:32" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=32 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=32 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation
06-4e-03 and 06-5e-03 microcode files have been reverted by the upstream in microcode-20200616 release due to [1]. You can try to use microcode_ctl-2.1-38 that includes revision 0xdc of the aforementioned microcode files for the time being. [1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
microcode-20201110 release[1] updates 06-4e-03 microcode to revision 0xe2 that contains mitigations against CVE-2020-0543. [1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20201110
FEDORA-2020-14fda1bf85 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-14fda1bf85
FEDORA-2020-bc0c5f2527 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-bc0c5f2527
FEDORA-2020-79bd31e5d9 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-79bd31e5d9
FEDORA-2020-bc0c5f2527 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-bc0c5f2527` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bc0c5f2527 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-1afbe7ba2d has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1afbe7ba2d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1afbe7ba2d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-1afbe7ba2d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
According to speed47's checker, the bug still exists: https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)' * Mitigated according to the /sys interface: NO (Vulnerable: No microcode) * SRBDS mitigation control is supported by the kernel: YES (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation) * SRBDS mitigation control is enabled and active: NO > STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability) How do I activate the protection ? CPU info: vendor_id : GenuineIntel cpu family : 6 model : 78 model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz stepping : 3 microcode : 0xd6 cpu MHz : 1132.810 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds bogomips : 4800.00 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:
I may be wrong as the checker just checks if the CPU is in a family architecture or not.
May I ask to provide output of the "rpm -qa microcode_ctl" command? The 0xd6 revision does not seem right, microcode_ctl-2.1-39.3.fc32 contains revision 0xe2 of the 06-4e-03 microcode.
(In reply to Eugene Syromiatnikov from comment #11) > May I ask to provide output of the "rpm -qa microcode_ctl" command? The > 0xd6 revision does not seem right, microcode_ctl-2.1-39.3.fc32 contains > revision 0xe2 of the 06-4e-03 microcode. $ rpm -qa microcode_ctl microcode_ctl-2.1-39.3.fc32.x86_64 Let me know if you need any other info from my side.
Ah, I suppose that the microcode_ctl package was the only one updated, and in Fedora it doesn't trigger initramfs regeneration as of now. May I ask to re-generate initramfs manually with 'sudo dracut -f --kver "$(uname -r)"' command and try again? See also [1]. [1] https://fedoraproject.org/wiki/QA:Testcase_microcode_update
(In reply to Eugene Syromiatnikov from comment #13) > Ah, I suppose that the microcode_ctl package was the only one updated, and > in Fedora it doesn't trigger initramfs regeneration as of now. May I ask to > re-generate initramfs manually with 'sudo dracut -f --kver "$(uname -r)"' > command and try again? See also [1]. > > [1] https://fedoraproject.org/wiki/QA:Testcase_microcode_update Success. Thanks for fixing the bug. Closing this issue.
(In reply to Eugene Syromiatnikov from comment #13) > Ah, I suppose that the microcode_ctl package was the only one updated, and > in Fedora it doesn't trigger initramfs regeneration as of now. May I ask to > re-generate initramfs manually with 'sudo dracut -f --kver "$(uname -r)"' > command and try again? See also [1]. > > [1] https://fedoraproject.org/wiki/QA:Testcase_microcode_update Actually I think only you guys can close it.