Bug#903135: intel-microcode: Kabby Lake microcode rev 0x84 instead of rev 0x8e
Just to keep this updated, after a reboot the message persists. On Thu, 2 Aug 2018 10:28:49 -0700 "E. B." mailto:roy...@gmail.com> > wrote: > Just today my machine pulled this update > > amd64-microcode (3.20180524.1~ubuntu0.18.04.2) > > Should this message go away on the next reboot? > > > >
Bug#903135: intel-microcode: Kabby Lake microcode rev 0x84 instead of rev 0x8e
Just today my machine pulled this update amd64-microcode (3.20180524.1~ubuntu0.18.04.2) Should this message go away on the next reboot?
Bug#903135: intel-microcode: Kabby Lake microcode rev 0x84 instead of rev 0x8e
On Sunday, July 8, 2018 1:40:34 PM PDT Henrique de Moraes Holschuh wrote: > On Fri, 06 Jul 2018, Matt Stamp wrote: > > After applying an update to my UEFI/BIOS my microcode is rev 0x8e. A > > package seperate for your, needrestart said that the available > > microcode did not match my currently applied version 0x84. Though > > even after the recent update from Intel I am still getting that > > message. > > That's a limitation in the needsrestart logic, which isn't easy to fix > at all. The kernel doesn't help (it doesn't tell you the BIOS microcode > revision on Intel, only the current revision), and Intel doesn't help > (they sometimes downgrade or recall microcode updates so you can't > assume it will just go up on intel-microcode updates), so it can't do a > perfect job. > > Maybe it can be improved, but that would be something to explore in a > bug report against needrestart, not intel-microcode. > > > Is this correct? Is the revision in intel-microcode-3.20180703.2 for > > Kabby Lake really 0x84? According to some of my reading Intel > > Yes, it is really 0x84, unfortunately(?) > > This information can be found in /usr/share/doc/intel-microcode/ > changelog.gz, although it can be a bit cryptic unless you've read the > README or tried running "iucode_tool -Sv" to know your processor's > signature. > > > released the 0x8e version and so I thought it would be included in > > their recent release. > > We wish. No, it isn't. From the Debian changelog of intel-microcode: > > --8<-- > + First batch of fixes for: Intel SA-00115, CVE-2018-3639, CVE-2018-3640 > + SSBD support (Spectre-v4 mitigation) and fix Spectre-v3a for: Sandybridge > server, Ivy Bridge server, Haswell server, Skylake server, Broadwell > server, a few HEDT Core i7/i9 models that are actually gimped server dies. > --8<-- > > As you can see, the vast majority of the processors affected, Kaby lake > included, are still missing in the public update release of 2018-07-03. > > > If this is some issue with the needrestart package or perl within than > > no big deal and please feel free to close this ticket. > > I will close the bug report when we get a Kabi Lake update with revision > 0x8e or higher. > > If you want to ask the needrestart package to improve their detection, > please open a bug against that package. I am not sure much can be done > on that regard without kernel changes, though. Thank you kindly for explaining that in detail. It is much appreciated.
Bug#903135: intel-microcode: Kabby Lake microcode rev 0x84 instead of rev 0x8e
On Fri, 06 Jul 2018, Matt Stamp wrote: > After applying an update to my UEFI/BIOS my microcode is rev 0x8e. A > package seperate for your, needrestart said that the available > microcode did not match my currently applied version 0x84. Though > even after the recent update from Intel I am still getting that > message. That's a limitation in the needsrestart logic, which isn't easy to fix at all. The kernel doesn't help (it doesn't tell you the BIOS microcode revision on Intel, only the current revision), and Intel doesn't help (they sometimes downgrade or recall microcode updates so you can't assume it will just go up on intel-microcode updates), so it can't do a perfect job. Maybe it can be improved, but that would be something to explore in a bug report against needrestart, not intel-microcode. > Is this correct? Is the revision in intel-microcode-3.20180703.2 for > Kabby Lake really 0x84? According to some of my reading Intel Yes, it is really 0x84, unfortunately(?) This information can be found in /usr/share/doc/intel-microcode/ changelog.gz, although it can be a bit cryptic unless you've read the README or tried running "iucode_tool -Sv" to know your processor's signature. > released the 0x8e version and so I thought it would be included in > their recent release. We wish. No, it isn't. From the Debian changelog of intel-microcode: --8<-- + First batch of fixes for: Intel SA-00115, CVE-2018-3639, CVE-2018-3640 + SSBD support (Spectre-v4 mitigation) and fix Spectre-v3a for: Sandybridge server, Ivy Bridge server, Haswell server, Skylake server, Broadwell server, a few HEDT Core i7/i9 models that are actually gimped server dies. --8<-- As you can see, the vast majority of the processors affected, Kaby lake included, are still missing in the public update release of 2018-07-03. > If this is some issue with the needrestart package or perl within than > no big deal and please feel free to close this ticket. I will close the bug report when we get a Kabi Lake update with revision 0x8e or higher. If you want to ask the needrestart package to improve their detection, please open a bug against that package. I am not sure much can be done on that regard without kernel changes, though. -- Henrique Holschuh
Bug#903135: intel-microcode: Kabby Lake microcode rev 0x84 instead of rev 0x8e
Package: intel-microcode Version: 3.20180703.2 Severity: normal Dear Maintainer, After applying an update to my UEFI/BIOS my microcode is rev 0x8e. A package seperate for your, needrestart said that the available microcode did not match my currently applied version 0x84. Though even after the recent update from Intel I am still getting that message. The currently running processor microcode revision is 0x8e which is not the expected microcode revision 0x84. Is this correct? Is the revision in intel-microcode-3.20180703.2 for Kabby Lake really 0x84? According to some of my reading Intel released the 0x8e version and so I thought it would be included in their recent release. If this is some issue with the needrestart package or perl within than no big deal and please feel free to close this ticket. I'm just looking for confirmation I suppose. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 142 model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz stepping: 9 microcode : 0x8e cpu MHz : 1152.470 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 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 tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx 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 fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass bogomips: 5808.00 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages intel-microcode depends on: ii iucode-tool 2.3.1-1 Versions of packages intel-microcode recommends: ii initramfs-tools 0.130 intel-microcode suggests no packages. -- no debconf information
