☰

如何检查我的系统上是否启用了微码以及如何修复导致重启问题的英特尔CPU固件包

tag-icon • tag-icon linux centos cpu intel vulnerability
如何检查我的系统上是否启用了微码以及如何修复导致重启问题的英特尔CPU固件包

修复来自英特尔的 cpu 固件包似乎会导致重启问题

我正在使用centos 7.3发行版1.14.14 kernel，想知道哪个软件包是英特尔的 CPU 固件以及哪个版本有问题以及如何修复它。

虽然我觉得这个微码包是正确的。

我也提到过这个文档但它没有提到确切的包名称和版本。

系统信息：

sh-4.2# cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 62
model name  : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping    : 4
microcode   : 0x42a
cpu MHz     : 2499.980
cache size  : 25600 KB
physical id : 0
siblings    : 2
core id     : 0
cpu cores   : 1
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cpuid_fault pti retpoline fsgsbase smep erms xsaveopt
bugs        : cpu_meltdown spectre_v1 spectre_v2
bogomips    : 5000.16
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model       : 62
model name  : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping    : 4
microcode   : 0x42a
cpu MHz     : 2499.980
cache size  : 25600 KB
physical id : 0
siblings    : 2
core id     : 0
cpu cores   : 1
apicid      : 1
initial apicid  : 1
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cpuid_fault pti retpoline fsgsbase smep erms xsaveopt
bugs        : cpu_meltdown spectre_v1 spectre_v2
bogomips    : 5000.16
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

sh-4.2#

微码包

sh-4.2# yum list installed | grep microcode
microcode_ctl.x86_64             2:2.1-22.5.el7_4                   @updates    
sh-4.2#

还想知道：

  1. 微码是正确的英特尔 CPU 固件包吗？
  2. microcode_ctl 实际上做了什么？
  3. 如何将微码值/proc/cpuinfo与microcode_ctl软件包版本进行映射，以识别有问题的软件包？

更新：

我能够比较英特尔列出的软件包版本这里与我的系统包。首先，我CPUID通过运行这些命令来了解我的系统yum install cpuid && cpuid | grep serial，并检查相应的影响版本CPUID 这里。看来我正在使用受影响的包，0x42a我将此版本与cat /proc/cpuinfo | grep microcode.不受影响的0x428是这个包microcode_ctl-2.1-16.3.el7_3.x86_64。我安装了这个软件包，但无法确定我的系统是否启用了微代码。

我还有几个问题 -

  1. 不确定我的机器是否microcode在启动时启用。我厌倦了这些命令并且它没有输出任何内容dmesg | grep microcode。我还检查了它，grep -i 'microcode' /boot/config-$(uname -r)它显示微代码配置设置为“是”，但仍在启动时间日志中，dmesg | grep microcode它什么也没显示。这里是否真的启用了微代码，如果没有，如何启用它。
  2. 我也提到了这个博客启用微代码，但卡在这一步，echo 1 > /sys/devices/system/cpu/microcode/reload即使使用 root 用户，系统也不允许创建此文件。

答案1

有问题的微代码以及针对 Spectre Variant 2 漏洞的仓促开发缓解措施已于 1 月 3 日（针对 RHEL）和 1 月 4 日（针对 CentOS）发布：https://lists.centos.org/pipermail/centos-announce/2018-January/022697.html

后来，该包中包含的用于 Broadwell 和 Haswell 处理器的微代码被证明存在问题并被回滚： https://access.redhat.com/errata/RHSA-2018:0093

根据后一个 RedHat 安全公告，您的microcode_ctl软件包版本 2:2.1-22.5.el7_4 是已经回滚了问题微码的版本。但是微代码更新已内置到您的initramfs文件中，因此如果您怀疑仍然存在与微代码相关的问题，只需重新创建initramfs文件（通常是mkinitrd命令，或者dracut对于 RHEL/Centos 7 及更高版本）。

该microcode_ctl软件包包含实际的微代码文件和一些用于将正确的微代码更新构建到文件中的工具initramfs。实际的微代码文件安装在/lib/firmware/intel-ucode：有相当多的小文件，一个对应于曾经需要微代码更新的每种英特尔处理器型号。

对于某些英特尔 CPU，事实证明，在某些情况下，有必要在启动过程中尽早应用微代码更新，以避免某些硬件错误。

/sys/devices/system/cpu/microcode/reload（更具体地说，对于 /proc/cpuinfo 型号代码为 79 和原始微码的 Intel 处理器，如果在系统以正常 SMP 模式运行时使用更新过程是不可靠的。可以通过让 BIOS 安装微码更新或在早期启动时安装更新，而启动过程尚未启动所有核心并且仍仅在一个核心上运行。）

为此，Linux 中开发了“早期微代码加载”工具。如果 initrd/initramfs 文件包含名为kernel/x86/microcode/GenuineIntel.bin(对于 Intel) 或(对于 AMD)的文件kernel/x86/microcode/AuthenticAMD.bin，则内核会在启动过程的早期尝试将其作为微代码更新加载。此功能不需要用户空间工具。

在 RHEL/Centos 7 上，要查看 initramfs 文件是否包含早期微代码更新文件，请运行以下命令：

lsinitrd /boot/initramfs-$(uname -r).img | less

如果输出的开头如下所示，则包含微代码更新：

Image: /boot/initramfs-3.10.0-693.el7.x86_64.img: 20M
========================================================================
Early CPIO image
========================================================================
drwxr-xr-x   3 root     root            0 Oct 11 05:11 .
-rw-r--r--   1 root     root            2 Oct 11 05:11 early_cpio
drwxr-xr-x   3 root     root            0 Oct 11 05:11 kernel
drwxr-xr-x   3 root     root            0 Oct 11 05:11 kernel/x86
drwxr-xr-x   2 root     root            0 Oct 11 05:11 kernel/x86/microcode
-rw-r--r--   1 root     root        12288 Oct 11 05:11 kernel/x86/microcode/GenuineIntel.bin
========================================================================
Version: dracut-033-502.el7

Arguments: -f -v

[... main initrd contents skipped ...]

除了实际的微代码文件之外，microcode_ctlRPM 包还包含以下内容：

  • /usr/lib/dracut/dracut.conf.d/01-microcode.conf，该文件告诉dracut（initramfs 创建者）将早期微代码更新添加到 initramfs 文件中。
  • /usr/lib/systemd/system/microcode.service它用于/sys/devices/system/cpu/microcode/reload加载微代码更新，以防早期微代码更新被禁用或无法运行。对于型号代码为 79 的 Intel CPU 有一个特殊的例外：在这些 CPU 上它什么也不做。
  • /usr/sbin/intel-microcode2ucode，一个用于将 Intel 微码文件转换为 Linux 微码更新机制可用的格式的工具。
  • 中的自述文件/usr/share/doc/microcode_ctl/README。

如果您在虚拟机上运行，​​那么您不必关心微代码更新 - 这是虚拟化主机（VM）管理员的工作不能做吧。即使您安装了microcode_ctl软件包，如果您在虚拟机上运行，​​它也不会执行任何操作。

要回滚有问题的微代码，您需要从系统中消除有问题的微代码的所有来源：

  • 回滚包含有问题固件的所有固件升级
  • 确保该microcode_ctl包是已回滚问题微代码的版本（您已完成此操作）
  • 确保 initramfs 文件已更新以匹配当前安装的microcode_ctl软件包的安装时间

然后掉电并重新启动。微代码在电源周期内是非持久性的，但如果 CPU 已经加载了较新的微代码版本，则它不会接受版本号较低的微代码更新。

相关内容