amd ucode что это

Intel опять обновила микрокод всех процессоров

Первые 192 байта старого недокументированного апдейта с микрокодом для Core i5 M460. Красным подсвечен номер ревизии, жёлтым — дата выпуска, зелёным — размер апдейта (в 4-байтовых словах), синим — подпись процессора

26 января 2021 года Microsoft выпустила набор обновлений микрокода для процессоров Intel под операционные системы Windows 10 20H2, 2004, 1909 и более старых версий, вплоть до 1507, а также для Windows Server.

Обычно такие апдейты закрывают возможность эксплуатации серьёзных аппаратных уязвимостей в CPU, таких как Spectre, Meltdown, Microarchitectural Data Sampling (MDS) и Platypus. По традиции, микрокод Intel не документируется. В прошлом специалисты пытались провести реверс-инжиниринг.

Intel подготовила микрокод и направила разработчикам операционных систем, чтобы закрыть или снизить ущерб от этих уязвимостей. В данном случае апдейт опциональный и «производит откат к обновлениям микрокода, которые закрывают уязвимости Spectre Variant 3a (CVE-2018-3640: «Rogue System Register Read (RSRE)»), Spectre Variant 4 (CVE-2018-3639: «Speculative Store Bypass (SSB)») и L1TF (CVE-2018-3620, CVE-2018-3646: «L1 Terminal Fault»)».

Обновления адресованы для большого списка десктопных, серверных и мобильных процессоров Intel всех семейств, кодовые названия продуктов: 10-е поколение Intel Core, Amber Lake (8-е поколение Intel Core), Apollo Lake, Broadwell, Cascade Lake, Cherry View, Coffee Lake, Comet Lake, Denverton, Gemini Lake, Haswell, Ice Lake, Kaby Lake, Lakefield, Sandy Bridge, Skylake, Valley View, Whiskey Lake. Полный список CPU см. в описании каждого обновления на сайте Microsoft (ссылки ниже).

Нужно подчеркнуть, что аппаратные уязвимости Spectre и Meltdown присущи всем процессорам Intel. Например, уязвимость Spectre (и смежная Meltdown) эксплуатирует механизм предсказания ветвлений в CPU и позволяет проводить чтение данных через сторонний канал в виде общей иерархии кэш-памяти.

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

Эти уязвимости присутствуют во всех современных процессорах (кроме RISC и российского «Эльбруса»), потому что предсказание ветвлений стало фундаментальной частью архитектуры современных CPU, от которой невозможно отказаться без значительной потери производительности.

Первые обновления микрокода Intel выпустила в январе 2018 года для всех операционных систем. Правда, первые версии Линус Торвальдс назвал «абсолютнейшим мусором», Intel попросила их больше устанавливать, а потом перевыпустила.

Первый патч для Windows 10 тоже пришлось отозвать, а потом перевыпустить.

С тех пор Intel выпустила ещё несколько обновлений. Все они устанавливаются через операционную систему без перепрошивки BIOS. Например, апдейты для процессоров Intel под Windows 10 выходили также 29 августа 2019 года, 30 января, 25 февраля, 1 сентября и 10 ноября 2020 года.

Остаётся надеяться, что с новыми апдейтами для Windows 10 всё обойдётся без приключений.

Список обновлений

«Наши модели, наши ментальные модели ошибочны; мы пожертвовали безопасностью ради производительности и сложности, и не знали об этом. Сейчас горькая ирония заключается в том, что для защиты требуется внедрение ещё большей сложности с помощью программных средств, большинство из которых, как мы знаем, являются неполными… Похоже, Spectre получил слишком удачное название, потому что ему суждено ещё долго нас преследовать». — «Spectre is here to stay. An analysis of side-channels and speculative execution», arXiv:1902.05178v1

Источник

Microcode

Processor manufacturers release stability and security updates to the processor microcode. These updates provide bug fixes that can be critical to the stability of your system. Without them, you may experience spurious crashes or unexpected system halts that can be difficult to track down.

All users with an AMD or Intel CPU should install the microcode updates to ensure system stability.

Microcode updates are usually shipped with the motherboard’s firmware and applied during firmware initialization. Since OEMs might not release firmware updates in a timely fashion and old systems do not get new firmware updates at all, the ability to apply CPU microcode updates during boot was added to the Linux kernel. The Linux microcode loader supports three loading methods:

Contents

Early loading

Installation

Depending on the processor, install the following package:

Microcode must be loaded by the boot loader. Because of the wide variability in users’ early-boot configuration, microcode updates may not be triggered automatically by Arch’s default configuration. Many AUR kernels have followed the path of the official Arch kernels in this regard.

These updates must be enabled by adding /boot/amd-ucode.img or /boot/intel-ucode.img as the first initrd in the bootloader config file. This is before the normal initrd file. See below for instructions for common bootloaders.

Configuration

Enabling early microcode loading in custom kernels

grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately. After installing the microcode package, regenerate the GRUB config to activate loading the microcode update by running:

Alternatively, users that manage their GRUB config file manually can add /boot/cpu_manufacturer-ucode.img (or /cpu_manufacturer-ucode.img if /boot is a separate partition) as follows:

Repeat it for each menu entry.

systemd-boot

Use the initrd option to load the microcode, before the initial ramdisk, as follows:

The latest microcode cpu_manufacturer-ucode.img must be available at boot time in your EFI system partition (ESP). The ESP must be mounted as /boot in order to have the microcode updated every time amd-ucode or intel-ucode is updated. Otherwise, copy /boot/cpu_manufacturer-ucode.img to your ESP at every update of the microcode package.

Unified kernel images

For unified kernel images, first concatenate the microcode file and your initrd, as follows:

Then build the unified kernel image as before, but passing /tmp/combined_initrd.img as the initrd. This file can then be deleted.

EFISTUB

Append two initrd= options:

rEFInd

Edit boot options in /boot/refind_linux.conf and add initrd=boot\cpu_manufacturer-ucode.img (or initrd=cpu_manufacturer-ucode.img if /boot is a separate partition) as the first initramfs. For example:

Users employing manual stanzas in esp/EFI/refind/refind.conf to define the kernels should simply add initrd=boot\cpu_manufacturer-ucode.img (or initrd=cpu_manufacturer-ucode.img if /boot is a separate partition) as required to the options line, and not in the main part of the stanza. E.g.:

Syslinux

Multiple initrd’s can be separated by commas in /boot/syslinux/syslinux.cfg :

LILO and potentially other old bootloaders do not support multiple initrd images. In that case, cpu_manufacturer-ucode.img and initramfs-linux.img will have to be merged into one image.

Now, edit /etc/lilo.conf to load the new image.

And run lilo as root:

Late loading

For Intel processors no package provides the microcode update files (FS#59841). To use late loading you need to manually extract intel-ucode/ from Intel’s provided archive.

Enabling late microcode updates

This allows to apply newer microcode updates without rebooting the system. For linux-firmware you can automate it with a pacman hook, e.g.:

Disabling late microcode updates

For AMD systems the CPU microcode will get updated even if amd-ucode is not installed since the files in /usr/lib/firmware/amd-ucode/ are provided by the linux-firmware package (FS#59840).

Microcode built in the initramfs

This article or section needs expansion.

The factual accuracy of this article or section is disputed.

This article or section needs expansion.

Verifying that microcode got updated on boot

Check the kernel messages with journalctl to see if the microcode has been updated:

On Intel systems one should see something similar to the following on every boot, indicating that microcode is updated very early on:

It is entirely possible, particularly with newer hardware, that there is no microcode update for the CPU. In that case, the output may look like this:

On AMD systems using early loading the output would look something like this:

On AMD systems using late loading the output will show the version of the old microcode before reloading the microcode and the new one once it is reloaded. It would look something like this:

Which CPUs accept microcode updates

Users may consult either Intel or AMD at the following links to see if a particular model is supported:

Detecting available microcode update

Источник

Microcode (Русский)

Производители процессоров выпускают обновления стабильности и безопасности для микрокода процессора. Несмотря на то, что микрокод можно обновить с помощью BIOS, ядро Linux также может применять эти обновления во время загрузки. Эти обновления предоставляют исправления ошибок, которые могут быть критичны для стабильности вашей системы. Без этих обновлений вы можете наблюдать ложные падения или неожиданные зависания системы, которые может быть сложно отследить.

Особенно пользователи процессоров семейства Intel Haswell и Broadwell должны установить эти обновления, чтобы обеспечить стабильность системы. Но, понятное дело, все пользователи должны устанавливать эти обновления.

Contents

Установка

Если Arch находится на съемном носителе, вы должны установить микрокод для обоих производителей процессоров.

Включение раннего обновления микрокода

Микрокод должен быть загружен загрузчиком. Из-за большого разнообразия конфигураций ранней загрузки у пользователей обновления микрокода могут быть не применены автоматически конфигурацией Arch по умолчанию. Многие ядра в AUR пошли по пути официальных ядер Arch в этом вопросе.

Чтобы применить эти обновления, добавьте /boot/amd-ucode.img или /boot/intel-ucode.img в качестве первого initrd в конфигурационном файле загрузчика. Это в дополнение к обычному initrd файлу. Смотрите ниже инструкции для популярных загрузчиков.

Автоматический способ

Утилита grub-mkconfig автоматически определит обновления микрокода и настроит соответственным образом GRUB. После установки пакета микрокода, перегенерируйте настройки GRUB, чтобы включить обновление микрокода при запуске:

Ручной способ

Повторите это для каждой записи в меню.

systemd-boot

Используйте параметры initrd для загрузки микрокода перед исходным ramdisk следующим образом:

EFI boot stub / EFI handover

Добавьте два параметра initrd= :

The factual accuracy of this article or section is disputed.

Для ядер, которые были сгенерированы как один файл, содержащий все initrd, cmdline и ядро, сначала сгенерируйте initrd для интеграции, создав новый, следующим образом:

rEFInd

Отредактируйте опции загрузки в /boot/refind_linux.conf также как в примере EFI boot stub выше, например:

Syslinux

Несколько файлов initrd могут быть разделены запятыми в /boot/syslinux/syslinux.cfg :

LILO и потенциально другие старые загрузчики не поддерживают несколько образов initrd. В этом случае необходимо объединить производитель_цп-ucode.img и initramfs-linux.img в один образ.

Теперь отредактируйте /etc/lilo.conf для загрузки нового образа.

И запустите lilo от суперпользователя:

Позднее обновление микрокода

Для процессоров Intel ни один пакет не предоставляет файлы обновления микрокода (FS#59841). Чтобы использовать позднюю загрузку, вам необходимо вручную извлечь intel-ucode/ из предоставленного Intel архива.

Включение позднего обновления микрокода

Для ручного обновления микрокода на запущенной системе запустите:

Это позволяет применять обновления микрокода после обновления linux-firmware без перезагрузки системы. Вы можете даже автоматизировать это с помощью хука pacman, например:

Отключение позднего обновления микрокода

Проверим, обновился ли microcode при загрузке

Чтобы убедиться, что микрокод обновился, воспользуемся dmesg:

На системах Intel вы должны увидеть что-то похожее на это при каждой загрузке, что говорит о том, что микрокод обновился рано:

Вполне возможно, особенно с новым аппаратным обеспечением, что для вашего CPU нет обновления микрокода. В этом случае вы можете увидеть примерно следующее:

На системах AMD, использующих раннюю загрузку, вывод будет выглядеть примерно так:

Каким ЦП нужны обновления микрокода

Пользователи могут проконсультироваться как у Intel, так и у AMD насчёт поддержки конкретной модели процессора, перейдя по следующим ссылкам:

Обнаружение доступного обновления микрокода

Применение ранней загрузки микрокода в кастомных ядрах

Источник

AMD microcode

This article describes updating the microcode for AMD processors.

Contents

Installation

Emerge

Microcode updates for AMD processors are provided by sys-kernel/linux-firmware package. Install the package via:

Kernel

In order to load the CPU microcode the following kernel options should be enabled:

Configuration

There are multiple ways how to update the microcode.

Built-in firmware

This way the firmware files will be built directly into the kernel.

Firmware blob files selection

You can either include all the available AMD firmware files to the kernel or select just the one specific for your CPU.

All firmware files

This setup simply builds all the firmware blobs into the kernel. This can be achieved by the following kernel optionsː

Specific firmware only

This way you only include the firmware suitable to your current CPU family. The CPU family identification can be obtained from /proc/cpuinfo :

In this example the CPU belongs to the AMD CPU family 22.

The following table helps to identify the right firmware blob file for given CPU family identificator:

The previously identified CPU specific firmware blob file (in this example CPU family 22) needs to be built into the kernelː

Initrd

You can load the microcode with the initrd. This way the firmware blobs are not inside the kernel, which will instead look for them in the loaded initrd.

Kernel

In order to use the initrd, you have to enable it in the kernel:

Firmware files preparation

First create the specified directory and cd into it. It doesn’t have to be in /tmp but the kernel/x86/microcode part is necessary.

Then we concatenate all the AMD firmware files into a single file. As before the path and filename of the output file must not be altered.

Then we will create a cpio archive in /boot/amd-uc.img using bsdcpio from app-arch/libarchive:

Alternatively, enable the initramfs USE flag for sys-kernel/linux-firmware to get /boot/amd-uc.img.

GRUB2 configuration

Since the image file /boot/amd-uc.img is one of the recognized ones by GRUB2 we just need to regenerate grub config.

It should show that it found the /boot/amd-uc.img file.

Building the kernel

Verification

After the next reboot with the new kernel, you should see a similar output:

The first line contains the microcode: updated early log message in case a microcode update was performed during the boot.

Источник

AMD Microcode, как?

Не грузится AMD_Microcode на обоих компах: что на Арче, что на Дженте.

Как сделать, чтоб грузилось? Arch:

а что в этом открытом амд даже процессор не работает без блобопрошивок

посмотрите для каких камней микрокод, там далеко не все модели

в bios уже свежий микрокод, например

Как не про Интел, а про АМД.

на турион почти 100% нету апдейтов

было кажется на феном 945 кажись, сейчас уточню

если не было, тогда почему Микрокоды одинаковые, иль я чего не догоняю?

это ж турион свежий вроде?

так там не для всех камней обновление есть, вроде бы.

хм, похоже и всё так работало

а с чего ты взял, что он не грузится?

Так и напиши по этому адресу и потребуй объяснений!

c того, что обычно присутствует слово «updated»

Простите, а как связан биос и микрокод?

микрокод выпускают только тогда когда в старой версии найдены ошибки ЕМНИП.

c того, что обычно присутствует слово «updated»

легко проверить: arch/x86/kernel/cpu/microcode/

и дебаг левел соотв.:

тож думаю, что никак.

ядра, таки, думаю, что разные.

т.е. в моём биосе таки устаревший микрокод процессора (если он там вообще есть)? 0x1a vs 0x29, в таком случае можно предположить, что асус не поставляет необязательные обновления микрокода с биосом.

васче, насколько я знаю, БИОС матплаты к микрокоду процессора никакого отношения не имеет.

особо критичные фиксы было дело запихивали.

но обновлением микрокода у амд тогда еще и не пахло.

заблэклистил модуль микрокода, потом вручную подгрузил

Имеет. Прямое. Микрокод имеется в биосе. И некоторые биосы, если находят проц к которому нет микрокода, вообще отказываются бутиться. Характерно для интелов (особенно 370/478/775 сокет).

у амд обновления микрокода в апдейты не вшиваются.

и выходило их 2 или 3 в отличие от интелей

в данном случае, ни о какой загрузки и поддержки матплатой проца речи не идёт. речь о, скорее всего, блокировании ранее объявленныъ функций на деле оказавшихся неработоспособными, как недавно у Интела. Микрокод из БИОСа никак не определяется и не подгружается, в отличие от модуль microcode, который в себе несёт обновление микрокода, причём на уровне операционной системы.

У меня на Xeon все грузится. Но я дефолтную директрию не менял ( /lib/firmware/microcode.dat ).

Вшивается. Посмотрите ревизии биосов. И да, именно от микрокодов зависит поддержка новых камней новыми биосами.

Микрокод из БИОСа никак не определяется и не подгружается

тот микрокод, что в БИОСе и этот немного разные. Модуль microcode подгружает только обновление микрокода, к-рое лежит в папке /lib/firmware, он не определяет микрокод, что зашит в БИОС. Задача этого микрокода блокировать инструкции, к-рые на деле оказались бажными или вообще неработающими.

где? в том что ты привёл — нет

расскажи как оно есть на самом деле.

The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle.

From what i’ve read its used to fix bugs in the cpu without modifying the BIOS. From my basic knowledge of assembler i know that assembly instructions are split into microcodes internally by the CPU and executed accordingly.

производитель публикует микрокод, его распространяют в обновлениях bios(пока производитель совесть не теряет) и linux-firmware

при старте bios микрокод подгружается в проц, при загрузке модуля он загружает в проц новый микрокод поверх, никуда он не зашивается

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

Источник