Исправлено от Intel в пакете прошивки процессора, похоже, вызывает проблемы с перезагрузкой

Я использую дистрибутив centos 7.3 с 1.14.14 kernel и хочу знать, какой пакет является прошивкой процессора Intel, а какая версия неисправна, и как это исправить.

Хотя я думаю, что этот пакет microcode является правильным.

Я также ссылался на этот документ но не упоминается точное имя и версия пакета.

Системная информация:

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. Является ли микрокод правильным пакетом прошивки процессора Intel?
  2. Что на самом деле делает microcode_ctl?
  3. Как сопоставить значение микрокода в /proc/cpuinfo с версией пакета microcode_ctl, чтобы определить неисправный пакет?

Обновление:

Мне удалось сравнить версию пакета, указанную Intel здесь с моим системным пакетом. Сначала я разобрался со своей системой 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.
2
mchawre 31 Янв 2018 в 09:21
Какие проблемы?
 – 
Kusalananda
24 Янв 2018 в 22:29
Я обновил свой вопрос и добавил больше деталей. Также изменили название.
 – 
mchawre
31 Янв 2018 в 09:23
Информации о "проблемах с перезагрузкой" пока нет. Что это за проблемы? Случайные перезагрузки? Не удалось перезагрузить? Необычные перезагрузки каким-то другим образом?
 – 
Kusalananda
31 Янв 2018 в 09:26
Подробная информация о проблемах с перезагрузкой предоставлена ​​Intel в официальном блоге. Вы можете проверить там. security-center.intel.com/…< /a> newsroom.intel.com/news/…
 – 
mchawre
31 Янв 2018 в 09:29

1 ответ

Проблемный микрокод с наспех разработанным средством защиты от уязвимости Spectre Variant 2 был выпущен 3 января для RHEL и 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: есть довольно много небольших файлов, по одному для каждой модели процессора Intel, которая когда-либо нуждалась в обновлении микрокода.

Для некоторых процессоров Intel оказалось, что в некоторых случаях было необходимо применить обновление микрокода как можно раньше в процессе загрузки, чтобы избежать определенных аппаратных ошибок.

(В частности, для процессоров Intel с кодом модели /proc/cpuinfo 79 и исходным микрокодом процесс обновления был ненадежным, если /sys/devices/system/cpu/microcode/reload использовалось, когда система работала в обычном режиме SMP. Этой ошибки можно было избежать, либо установив BIOS установить обновление микрокода или установить обновление при ранней загрузке, когда процесс загрузки еще не запустил все ядра и все еще выполнялся только на одном ядре.)

Для этой цели в Linux была разработана функция «ранней загрузки микрокода». Если файл initrd/initramfs содержит файл с именем kernel/x86/microcode/GenuineIntel.bin (для Intel) или kernel/x86/microcode/AuthenticAMD.bin (для AMD), ядро ​​пытается загрузить его как обновление микрокода в самом начале процесса загрузки. Для этой функции не требуются инструменты пользовательского пространства.

В 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 ...]

Помимо самих файлов микрокода, RPM-пакет microcode_ctl содержит следующие вещи:

  • /usr/lib/dracut/dracut.conf.d/01-microcode.conf, файл, сообщающий dracut (создателю initramfs) добавить раннее обновление микрокода в файл initramfs.
  • /usr/lib/systemd/system/microcode.service, который использует /sys/devices/system/cpu/microcode/reload для загрузки обновления микрокода в случае, если раннее обновление микрокода было отключено или не удалось запустить. У него есть специальное исключение для процессоров Intel с кодом модели 79: на этих процессорах он вообще ничего не делает.
  • /usr/sbin/intel-microcode2ucode, инструмент для преобразования файла микрокода Intel в формат, который может использоваться механизмом обновления микрокода Linux.
  • файл README в /usr/share/doc/microcode_ctl/README.

Если вы работаете на виртуальной машине, вам не нужно заботиться об обновлениях микрокода — это работа администратора хоста виртуализации, виртуальная машина не может этого делать. Даже если у вас установлен пакет microcode_ctl, он вообще ничего не сделает, если вы работаете на виртуальной машине.

Чтобы откатить проблемный микрокод, вам необходимо удалить все источники проблемного микрокода из вашей системы:

  • откатите все обновления прошивки, которые включают проблемную прошивку
  • убедитесь, что пакет microcode_ctl имеет откат проблемного микрокода (вы сделали это)
  • убедитесь, что файл initramfs обновлен, чтобы соответствовать времени установки текущего установленного пакета microcode_ctl

Затем выключите питание и перезагрузите компьютер. Микрокод не сохраняется в течение циклов питания, но если в ЦП уже загружена более новая версия микрокода, он не примет обновление микрокода с более низким номером версии.

3
telcoM 31 Янв 2018 в 13:00
Я обновил свой вопрос. Можете ли вы проверить и ответить, если это возможно.
 – 
mchawre
31 Янв 2018 в 09:27
Обновил свой ответ.
 – 
telcoM
31 Янв 2018 в 12:52
Итак, вы имеете в виду, что мне не нужно заботиться о пакете микрокода в случае виртуальной машины. Я вижу это в статусе microcode.service ● microcode.service - Load CPU microcode update Loaded: loaded (/usr/lib/systemd/system/microcode.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2018-02-01 16:33:22 UTC; 4s ago ConditionVirtualization=false was not met Поэтому, даже если в моей системе (VM) есть проблемный микрокод, он никогда не будет включен во время загрузки, и мне не нужно об этом беспокоиться.
 – 
mchawre
1 Фев 2018 в 19:42
Да... но если /proc/cpuinfo указывает на то, что процессор вашего хоста имеет поврежденный микрокод, то единственный способ избавиться от него - поручить это администраторам физического хоста.
 – 
telcoM
1 Фев 2018 в 23:43
Хорошо, но мы создаем собственные AMI, поэтому наша задача — вернуться к правильной версии микрокода.
 – 
mchawre
13 Фев 2018 в 11:56