Verification
After the next reboot, the loaded microcode revision can be verified by running:
microcode : 0x22 microcode : 0x22
The dmesg output should include:
microcode: microcode updated early to revision 0x22, date = 2017-01-27 microcode: sig=0x306c3, pf=0x2, revision=0x22 microcode: Microcode Update Driver: v2.2.
Here is an example of a CPU with no available microcode updates (microcode already current) or the system was not configured to load them properly:
microcode: CPU0 sig=0x6fd, pf=0x80, revision=0xa3 microcode: CPU1 sig=0x6fd, pf=0x80, revision=0xa3 microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba
Here is the same CPU but with microcode updates being applied successfully:
microcode: microcode updated early to revision 0xa4, date = 2010-10-02 microcode: CPU0 sig=0x6fd, pf=0x80, revision=0xa4 microcode: CPU1 sig=0x6fd, pf=0x80, revision=0xa4 microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba
NoteIf genkernel and legacy GRUB are used, the first line may be absent. Instead, check the microcode revision before and after the changes.
NoteNote how this is the very first step of the kernel logs now.
ImportantIt is possible the microcode has already been fully updated by your BIOS vendor. In that case the dmesg output does not contain the update log message.
NoteBe aware that injecting the microcode update directly into the motherboard firmware (which might sounds tempting) might result in CPU0 being updated but the rest of the CPUs (or CPU cores in a multi-core system) being left at their initial revision (which might cause more problems than running them all at the same initial version). And, since most stock motherboard firmware has some microcode updates (even in their initial release versions), it’s probably a good enough reason for everybody to make sure their kernel tries to update all CPUs (and cores) to the same version (so, let this update driver running even if the kernel has the same version which is stored in the motherboard firmware). Injecting the microcode into the firmware might be desirable still (to make sure it’s loaded for the boot CPU before the kernel is loaded and able to update the rest of the microcode).
New method without initram-fs/disk (efistub compatible)
WarningThis will only work on a 64-bit kernel and will have no effect otherwise. 32-bit systems need to use an initramfs.
NoteThis method should be preferable, especially for EFI-Stub systems (some motherboard firmware might have issues with parsing/passing custom boot command line options), since these changes are less likely to leave the system unbootable (and possibly unrepairable without an EFI compatible rescue disk which can be very tricky on headless machines) the way a broken firmware boot entry and/or incorrect initram-fs/disk would, while it also works on BIOS systems or EFI systems with custom bootloaders on disk. However, this requires a relatively recent kernel version (possibly unstable at the time of writing). It was tested with Linux 4.8.0
Software
To install microcode data files for the system processor(s):
FILE
MICROCODE_SIGNATURES="-S"
To install microcode data files for a specific processor use , or to exclude a specific processor. An empty or undefined MICROCODE_SIGNATURES variable will install all microcode data files.
Install the microcode data files:
iucode_tool: system has processor(s) with signature 0x000306c3
To find the appropriate filename(s) for the listed signature(s) use:
iucode_tool: system has processor(s) with signature 0x000306c3 microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03 selected microcodes: 049/001: sig 0x000306c3, pf_mask 0x32, 2017-01-27, rev 0x0022, size 22528
The signature is found in microcode bundle , so the filename to use is /lib/firmware/intel-ucode/06-3c-03.
Kernel
Enable and configure the CONFIG_MICROCODE, CONFIG_MICROCODE_INTEL, CONFIG_FIRMWARE_IN_KERNEL, CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR kernel options.
WarningEvery option must be set as built into the kernel, not as a kernel module.
KERNEL Enabling Microcode Loading Support
Processor type and features ---> <*> CPU microcode loading support Intel microcode loading support Device Drivers ---> Generic Driver Options ---> Firmware Loader ---> -*- Firmware loading facility (intel-ucode/06-3c-03) Build named firmware blobs into the kernel binary (/lib/firmware) Firmware blobs root directory (NEW)
NoteThe CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR options need to be set to the values identified by iucode_tool. In this example for an Intel i7-4790K processor, CONFIG_EXTRA_FIRMWARE is set to and CONFIG_EXTRA_FIRMWARE_DIR is set to .
NoteThe CONFIG_EXTRA_FIRMWARE option allows specifying multiple firmware files by listing them space-separated.
Rebuild and install the kernel as usual.
Каким ЦП нужны обновления микрокода
Пользователи могут проконсультироваться как у Intel, так и у AMD насчёт поддержки конкретной модели процессора, перейдя по следующим ссылкам:
Обнаружение доступного обновления микрокода
Вы можете узнать, содержит ли образ микрокода для вашего процессора с помощью .
- Установите (для обнаружения обновления не требуется менять initrd)
- Установите
-
# modprobe cpuid
- Извлекает образ микрокода и ищет в нём ваш cpuid:
# bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -
- Если обновление доступно, оно должно отобразиться под selected microcodes
- Микрокод может уже быть в вашем биосе и его загрузка может не отображаться в dmesg. Сравните с текущим запуском микрокода {ic|grep microcode /proc/cpuinfo}}
Возможность обновления
В середине 1990-х средство для поставки нового микрокода первоначально называлось функцией обновления BIOS Pentium Pro . Предполагалось, что приложения пользовательского режима должны вызывать прерывание BIOS для подачи нового «блока данных обновления BIOS», который BIOS будет частично проверять и сохранять в энергонезависимой памяти BIOS ; это может быть передано установленным процессорам при следующей загрузке.
Intel распространила переименованную программу , которую можно было запускать под DOS . Коллекции нескольких обновлений микрокода были объединены вместе и пронумерованы с расширением , например .
Интерфейс процессора
Процессор загружается с использованием набора микрокода, который хранится внутри процессора и хранится во внутреннем ПЗУ . Обновление микрокода заполняет отдельную SRAM и набор «регистров соответствия», которые действуют как точки останова в ПЗУ микрокода, чтобы позволить переход к обновленному списку микроопераций в SRAM. Сопоставление выполняется между указателем инструкции микрокода (UIP) и всеми регистрами сопоставления, при этом любое сопоставление приводит к переходу к соответствующему адресу микрокода назначения. В исходной архитектуре P6 есть место в SRAM для 60 микроопераций и нескольких пар регистров соответствия / назначения. Для перехода от микрокода ПЗУ к исправленному микрокоду, хранящемуся в SRAM, требуется один цикл команд процессора . Регистры совпадений состоят из адреса совпадения микрокода и адреса назначения микрокода.
Процессор должен быть в нулевом кольце защиты (« Кольцо 0 »), чтобы инициировать обновление микрокода. Каждый ЦП в симметричной многопроцессорной системе необходимо обновлять индивидуально.
Обновление инициируется помещением его адреса в регистр, установкой и выполнением (Запись в регистр конкретной модели ).
Формат обновления микрокода
Intel распространяет обновления микрокода в виде двоичных двоичных объектов размером 2048 (2 килобайта) . Обновление содержит информацию о том, для каких процессоров оно предназначено, так что это можно проверить по результату инструкции CPUID . Структура представляет собой 48-байтовый заголовок, за которым следуют 2000 байтов, предназначенные для чтения непосредственно процессором для обновления:
- Программа микрокода, которая выполняется процессором во время процесса обновления микрокода. Этот микрокод может реконфигурировать и включать или отключать компоненты, используя специальный регистр, и он должен обновлять регистры совпадения точек останова.
- До шестидесяти исправленных микроопераций для загрузки в SRAM.
- Заполнение, состоящее из случайных значений, чтобы затруднить понимание формата обновления микрокода.
Каждый блок кодируется по-разному, и большая часть из 2000 байтов не используется в качестве программы конфигурации, а само содержимое микроопераций SRAM намного меньше. Окончательное определение и проверка того, можно ли применить обновление к процессору, выполняется во время дешифрования через процессор. Каждое обновление микрокода зависит от конкретной версии ЦП и предназначено для отклонения ЦП с другим уровнем степпинга . Обновления микрокода зашифрованы, чтобы предотвратить подделку и включить проверку.
В Pentium есть два уровня шифрования, и точные детали явно не задокументированы Intel, а известны менее чем десяти сотрудникам.
Обновления микрокода для Intel Atom , Nehalem и Sandy Bridge дополнительно содержат дополнительный 520-байтовый заголовок, содержащий 2048-битный модуль RSA с десятичным показателем 17.
Микроархитектура | Примеры процессоров | Поставляемая длина | Функциональная длина | Подозреваемая кодировка |
---|---|---|---|---|
P6 | Pentium Pro | 2000 г. | 864; 872; 944; 1968 г. | 64-битный блочный шифр |
Основной | PIII… Core 2 | 4048 | 3096 | |
Netburst | P4 , Pentium D , Celeron | 2000–7120 | 2000 + N * 1024 | цепной блочный шифр |
Атом, Нехалем, Сэнди Бридж | Core i3 / i5 / i7 | 976–16336 | 976 + N * 1024; 5120 | Подпись AES + RSA |
Доступны обновления микрокода Intel для Windows 10, исправляющие уязвимости безопасности
Обновлено: 26.01.2021: Новые версии обновления микрокода Intel для Windows 10 предназначены для следующих семейств процессоров Intel:
Когда Intel обнаруживает ошибки в своих процессорах, то компания выпускает обновления микрокода, которые позволяют операционным системам корректировать поведение процессора, чтобы исправить или, по крайней мере, смягчить ошибку.
Накануне международная группа исследователей из Грацского Технического Университета, Центр им. Гельмгольца по информационной безопасности (CISPA) и Университета Бирмингема обнаружили новую уязвимость побочного канала процессоров Intel под названием Platypus.
Уязвимости типа Platypus находятся в интерфейсе Intel Running Average Power Limit (RAPL), который позволяет пользователям контролировать и управлять энергопотреблением поддерживаемых процессоров и памяти DRAM.
Исследователи показали на практике, как можно использовать интерфейс RAPL для мониторинга энергопотребления и определения того, какие инструкции выполняются ЦП с последующим извлечением конфиденциальных данных из памяти.
В качестве демонстрации исследователи опубликовали видео, в котором показано, как можно использовать атаку Platypus для кражи ключа AES-NI из защищенных анклавов Intel SGX.
Доступны обновления микропрограммы Intel
Во «Вторник Патчей», 10 ноября 2020 года, компания Microsoft выпустила обновления микрокода Intel для исправления уязвимостей в процессорах Intel, в том числе уязвимостей типа Platypus.
Также обновления исправляют и другие уязвимости:
Данные обновления микропрограммы Intel поддерживают следуюшие семейства процессоров:
Если ваше устройство оснащено одним из следующих процессоров, то в Центре обновления Windows будет автоматически предложено соответствующее обновление микропрограммы.
Обновления микропрограммы можно загрузить напрямую из Каталога Центра обновления Майкрософт:
Подробная информация об обновлениях и поддерживаемых процессорах
Пользователям рекомендуется как можно скорее установить обновления микрокода, но стоит отметить, что предыдущие обновления вызывали зависания системы и проблемы с производительностью на устройствах со старыми процессорами Intel.
После установки обновлений микрокода, для применения исправлений потребуется перезагрузка Windows 10. Не забудьте сохранить прогресс работы в приложениях перед запуском перезагрузки.
Поддерживается ли мой процессор?
Чтобы проверить, какой процессор установлен на вашем компьютере, можно воспользоваться Диспетчером устройств в Windows 10.
Щелкните правой кнопкой мыши по меню «Пуск» и выберите «Диспетчер устройств». Затем прокрутите список оборудования до категории «Процессоры» и раскройте список компонентов.
Если вы хотите узнать дополнительную информацию о процессоре, в том числе семейство процессоров, версию и номер модели ЦП, то воспользуйтесь утилитой CPU-Z.
дальнейшее чтение
- «первые Cuops в операции поворота REP загружаютСчетчик циклов MS с количеством итераций, оставшихся после выполнения развернутых итераций.… Небольшое количество итераций (например, семь) отправляется в течение времени, необходимого для загрузки счетчика циклов в MS. Этот развернутый код выполняется условно на основе значения (E) CX… оставшиеся три итерации преобразуются в NOPS ».
- «… управление возвращается к Micro -operation Sequence (MS) unit для дальнейшего исправления ошибок Управляющие микрооперации (Cuops). Чтобы упростить перезапуск, Cuops, возникающие из вызывающей ошибку макрокоманды, поставляемой матрицами программируемой логики translate (XLAT PLA), загружаются в Регистры Cuop с неустановленными действительными битами «.
- «ADD, XOR, SUB, AND и OR, которые реализованы с помощью одного универсального Cuop. Другая группа инструкций, представленных только одним Cuop, включает ADC и SBB.
- «SYSENTER и SYSEXIT являются сборкой- языковые инструкции, которые могут выполняться на процессоре архитектуры Intel, таком как процессор Pentium Pro… микрооперация считается готовой, когда ее исходные поля были заполнены соответствующими данными… блок декодирования инструкций включает один или несколько программируемых преобразований (XLAT) логические массивы (PLA), которые декодируют каждую инструкцию в одну или несколько микроопераций.… Инструкции SYSENTER и SYSEXIT декодируются в микрооперации, которые выполняют шаги, проиллюстрированные на фиг.5 и 6, соответственно ».
Проверим, обновился ли microcode при загрузке
Чтобы убедиться, что микрокод обновился, воспользуемся dmesg:
# dmesg | grep microcode
На системах Intel вы должны увидеть что-то похожее на это при каждой загрузке, что говорит о том, что микрокод обновился рано:
CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 CPU1 microcode updated early to revision 0x1b, date = 2014-05-29 CPU2 microcode updated early to revision 0x1b, date = 2014-05-29 CPU3 microcode updated early to revision 0x1b, date = 2014-05-29 microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b microcode: Microcode Update Driver: v2.2.
Примечание: Отображаемая дата отвечает не за версию установленного пакета . Это дата последнего обновления микрокода от Intel для вашего конкретного процессора.
Вполне возможно, особенно с новым аппаратным обеспечением, что для вашего CPU нет обновления микрокода. В этом случае вы можете увидеть примерно следующее:
microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c microcode: Microcode Update Driver: v2.2.
На системах AMD, использующих раннюю загрузку, вывод будет выглядеть примерно так:
microcode: microcode updated early to new patch_level=0x0700010f microcode: CPU0: patch_level=0x0700010f microcode: CPU1: patch_level=0x0700010f microcode: CPU2: patch_level=0x0700010f microcode: CPU3: patch_lev microcode: Microcode Update Driver: v2.2.
На системах AMD, использующих позднюю загрузку, в выводе будет отображаться версия старого микрокода перед перезагрузкой микрокода, а новая — после перезагрузки. Это будет выглядеть примерно так:
microcode: CPU0: patch_level=0x0700010b microcode: CPU1: patch_level=0x0700010b microcode: CPU2: patch_level=0x0700010b microcode: CPU3: patch_level=0x0700010b microcode: Microcode Update Driver: v2.2. microcode: CPU2: new patch_level=0x0700010f microcode: CPU0: new patch_level=0x0700010f microcode: CPU1: new patch_level=0x0700010f microcode: CPU3: new patch_level=0x0700010f x86/CPU: CPU features have changed after loading microcode, but might not take effect.
Микрооперации
В процессорах Intel 80486 и AMD Am486 в ПЗУ микрокода хранится около 250 строк микрокода общим объемом 12 032 бита.
На Pentium Pro каждая микрооперация имеет ширину 72 бита или 118 бит. Это включает в себя код операции, два исходных поля и одно поле назначения с возможностью хранения 32-битного немедленного значения. Pentium Pro может обнаруживать ошибки четности во внутреннем микрокоде ПЗУ и сообщать о них с помощью архитектуры машинной проверки .
Микрооперации имеют согласованный формат с тремя исходными входами и двумя выходами назначения. Процессор выполняет переименование регистров, чтобы отобразить эти входные данные в реальный регистровый файл (RRF) и из него до и после их выполнения. Используется неупорядоченное выполнение , поэтому микрооперации и инструкции, которые они представляют, могут не появляться в одном и том же порядке.
Во время разработки Pentium Pro между степпингами A2 и B0 было внесено несколько исправлений микрокода. Для Pentium II (на базе P6 Pentium Pro) были добавлены дополнительные микрооперации для поддержки набора инструкций MMX . В некоторых случаях были добавлены «помощники микрокода» для надежной обработки редких угловых случаев.
Pentium 4 может одновременно выполнять 126 микроопераций. Микрооперации декодируются и хранятся в кэше трассировки выполнения с 12 000 записей, чтобы избежать повторного декодирования одних и тех же инструкций x86. Группы из шести микроопераций упаковываются в линию трассировки. Микрооперации могут занимать дополнительное пространство для немедленных данных в той же строке кэша. Сложные инструкции, такие как обработка исключений, приводят к переходу к ПЗУ микрокода. Во время разработки Pentium 4 микрокод составлял 14% ошибок процессора по сравнению с 30% ошибок процессора во время разработки Pentium Pro.
Intel Core микроархитектура введен в 2006 году добавила « микро-операция слияния » для некоторых общих пар команд , включая сравнение с последующим скачком. Декодеры инструкций в Core преобразуют инструкции x86 в микрокод тремя различными способами:
x86 инструкции | x86 декодеры | микрооперации |
---|---|---|
общий | простой декодер × 3 | 1–3 |
большинство других | сложный декодер × 1 | ≤4 |
очень сложный | секвенсор микрокода | много |
Для реализации Intel Hyper-Threading для одновременной многопоточности , ПЗУ микрокода, кэш трассировки и декодеры инструкций являются общими, но очередь микроопераций не используется совместно.
Включение раннего обновления микрокода
Микрокод должен быть загружен загрузчиком. Из-за большого разнообразия конфигураций ранней загрузки у пользователей обновления микрокода могут быть не применены автоматически конфигурацией Arch по умолчанию. Многие ядра в AUR пошли по пути официальных ядер Arch в этом вопросе.
Чтобы применить эти обновления, добавьте или в качестве первого initrd в конфигурационном файле загрузчика. Это в дополнение к обычному initrd файлу. Смотрите ниже инструкции для популярных загрузчиков.
Примечание: В следующих разделах замените строку вашим производителем, например, или .
Совет: Для Arch Linux на съемном носителе добавьте оба файла в настройки загрузчика. Их порядок не имеет значения, если они оба указаны до реального образа initramfs.
GRUB
Автоматический способ
Утилита grub-mkconfig автоматически определит обновления микрокода и настроит соответственным образом GRUB. После установки пакета микрокода, перегенерируйте настройки GRUB, чтобы включить обновление микрокода при запуске:
# grub-mkconfig -o /boot/grub/grub.cfg
Ручной способ
Альтернативно пользователи, управляющие настройками GRUB вручную, могут добавить (или , если есть отдельный раздел ) следующим образом:
/boot/grub/grub.cfg
... echo 'Loading initial ramdisk' initrd /boot/производитель_цп-ucode.img /boot/initramfs-linux.img ...
Повторите это для каждой записи в меню.
systemd-boot
Используйте параметры для загрузки микрокода перед исходным ramdisk следующим образом:
/boot/loader/entries/запись.conf
title Arch Linux linux /vmlinuz-linux initrd /производитель_цп-ucode.img initrd /initramfs-linux.img ...
Самый последний микрокод должен быть доступен во время загрузки вашего системного раздела EFI (ESP). ESP должен быть смонтирован как , чтобы обновлять микрокод каждый раз, когда обновляется или . В противном случае копируйте в ваш ESP при каждом обновлении пакета микрокода.
EFI boot stub / EFI handover
Добавьте два параметра :
initrd=/производитель_цп-ucode.img initrd=/initramfs-linux.img
The factual accuracy of this article or section is disputed.
Reason: Что это делает, почему этого недостаточно, и почему/как это специфично для данного раздела? (Discuss in Talk:Microcode (Русский)#Addition in EFI Boot stub)
Для ядер, которые были сгенерированы как один файл, содержащий все initrd, cmdline и ядро, сначала сгенерируйте initrd для интеграции, создав новый, следующим образом:
cat /boot/производитель_цп-ucode.img /boot/initramfs-linux.img > my_new_initrd objcopy ... --add-section .initrd=my_new_initrd
rEFInd
Отредактируйте опции загрузки в также как в примере EFI boot stub выше, например:
"Boot with standard options" "rw root=UUID=(...) initrd=/boot/производитель_цп-ucode.img initrd=/boot/initramfs-linux.img"
Пользователи, использующие в для определения ядер, должны просто добавить (или , если есть отдельный раздел ), как требуется для строки опций, а не в основной части строфы. Например:
options "root=root=UUID=(...) rw add_efi_memmap initrd=/boot/производитель_цп-ucode.img"
Syslinux
Примечание: Между указаниями файлов initrd и не должно быть пробелов. Строка должна быть точно такой, как показано ниже.
Несколько файлов initrd могут быть разделены запятыми в :
LABEL arch MENU LABEL Arch Linux LINUX ../vmlinuz-linux INITRD ../производитель_цп-ucode.img,../initramfs-linux.img ...
LILO
LILO и потенциально другие старые загрузчики не поддерживают несколько образов initrd. В этом случае необходимо объединить и в один образ.
Важно: Объединенный образ нужно пересоздавать после каждого обновления ядра!
Примечание: Порядок важен. Исходный образ должен находиться сверху над образом .. Чтобы объединить образы в один , можно использовать следующую команду:
Чтобы объединить образы в один , можно использовать следующую команду:
# cat /boot/производитель_цп-ucode.img /boot/initramfs-linux.img > /boot/initramfs-merged.img
Теперь отредактируйте для загрузки нового образа.
... initrd=/boot/initramfs-merged.img ...
И запустите от суперпользователя:
# lilo
Отладка
Можно загрузить специальный микрокод для отладки, чтобы включить расширенную трассировку выполнения, которая затем выводит дополнительную информацию через выводы монитора точки останова. На Pentium 4 загрузка специального микрокода может дать доступ к режиму расширенного отслеживания выполнения микрокода. При использовании тестового порта доступа JTAG (TAP) пара регистров контроля точки останова позволяет взламывать адреса микрокода.
В середине 1980-х годов NEC и Intel уже давно рассматривали дело в федеральном суде США об авторском праве на микрокод. NEC уже выступает в качестве второго источника для Intel 8086 процессоров с его NEC μPD8086 и провел долгосрочные патентные и авторские права кросса-лицензионные соглашения с Intel. В августе 1982 года Intel подала в суд на NEC за нарушение авторских прав на реализацию микрокода. NEC преуспела, продемонстрировав с помощью разработки программного обеспечения для чистых помещений, что сходство в реализации микрокода на процессорах V20 и V30 было результатом ограничений, установленных архитектурой, а не путем копирования.
Intel 386 может выполнить встроенную самопроверку микрокода и программируемые логические матрицы , со значением самопроверки , помещенной в регистре. Во время BIST счетчик микропрограмм повторно используется для обхода всех ПЗУ с сопоставлением результатов через сеть регистров сигнатур с множеством входов (MISR) и регистров сдвига с линейной обратной связью. При запуске Intel 486 аппаратно-управляемый BIST работает в течение 2 20 тактов для проверки различных массивов, включая ПЗУ микрокода, после чего управление передается микрокоду для дальнейшего самотестирования регистров и вычислительных блоков. ПЗУ микрокода Intel 486 имеет 250 000 транзисторов.
AMD заключила долгосрочный контракт на повторное использование микрокода Intel 286, 386 и 486. В октябре 2004 года суд постановил, что соглашение не распространяется на распространение AMD микрокода Intel 486 внутрисхемной эмуляции (ICE).
Тестирование прямого доступа
Тестирование с прямым доступом (DAT) включено в процессоры Intel в рамках инициатив по разработке для тестирования (DFT) и Design for Debug (DFD), которые позволяют полностью тестировать отдельные ЦП перед продажей.
В мае 2020 года сценарий, считывающий непосредственно из шины регистров управления (CRBUS) (после использования «красной разблокировки» в JTAG USB-A to USB-A 3.0 с возможностями отладки, без D +, D- и Vcc) использовался для чтения из были прочитаны порт тестирования локального прямого доступа (LDAT) процессора Intel Goldmont и загруженный микрокод и массивы исправлений. Эти массивы доступны только после того, как ЦП был переведен в определенный режим, и состоят из пяти массивов, доступ к которым осуществляется через смещение 0x6a0:
- ПЗУ: триады микрокода
- ROM: Последовательные слова
- RAM: Последовательные слова (обновляется)
- RAM: пары Match / Patch (обновляется)
- RAM: триады микрокода (обновляемая)
Microsoft выпустила для Windows 10 и Windows Server большой комплект обновлений микрокодов для процессоров Intel
1 сентября 2020 года Microsoft выпустила для Windows 10 (версии 2004, 1909, 1903 и других версий), а также Windows Server большой комплект обновлений микрокодов для процессоров Intel. Обновления затронули большое количество различных процессоров Intel, которые входят в 11 различных семейств чипов производителя.
Microsoft пояснила, что Intel устранила в новых версиях микрокодов различные баги и реализовала патчи против нескольких уязвимостей (CVE-2019-11091, CVE-2018-12126, CVE-2018-12127 и CVE-2018-12130), которые затрагивают как клиентские платформы, так и серверные решения.
Семейства (кодовые имена) процессоров Intel, которые получили новые обновления микрокодов:
- Amber Lake (Y; Y/22);
- Avoton;
- Broadwell (DE A1; DE V1 — V3; DE Y0; H 43e; Server E, EP, EP4S; Server EX; U; Y; Xeon E);
- Cascade Lake (Lake Server; Lake-W);
- Coffee Lake (H (6+2); S (6+2); U43e; H (8+2); S (4+2); S (4+2) x/KBP; S (4+2) Xeon E; Coffee Lake S (4+2) Xeon E (U0); S (6+2) x/KBP; S (6+2) Xeon E; S (6+2) Xeon E (U0); S (8+2); S (8+2) x/KBP; S (8+2) Xeon E (R0); S/H (8+2) );
- Comet Lake (U42; U62);
- Haswell (Desktop; H / Haswell Perf Halo; Server EX; U; Xeon E3);
- Kaby Lake (G; H; Refresh U 4+2; S; U; U23e; X; Xeon E3; Y);
- Skylake (H; S; Server; U; U23e; Xeon E3; Y);
- Valley View / Baytail;
- Whiskey Lake (U42).
Обновления микрокодов Intel не устанавливаются автоматически через Центр обновления Windows. Пользователи или системные администраторы должны устанавливать их вручную.
Ссылки на обновления микрокодов Intel для различных версий Windows 10, а также Windows Server (внутри есть полный список затронутых обновлением процессоров):
- KB4558130: обновление для Windows 10 версии 2004;
- KB4497165: обновление для Windows 10 версий 1909 и 1903;
- KB4494174: обновление для Windows 10 версии 1809;
- KB4494451: обновление для Windows 10 версии 1803;
- KB4494452: обновление для Windows 10 версии 1709;
- KB4494453: обновление для Windows 10 версии 1703;
- KB4494175: обновление для Windows 10 версии 1607;
- KB4494454: обновление для Windows 10.
После установки обновления микрокода потребуется перезагрузка ОС.