2020-12-15 15:59:41 +00:00
|
|
|
|
The microcode_ctl package contains microcode files (vendor-provided binary data
|
|
|
|
|
|
and/or code in proprietary format that affects behaviour of a device) for Intel
|
|
|
|
|
|
CPUs that may be loaded into the CPU during boot.
|
|
|
|
|
|
|
|
|
|
|
|
The microcode_ctl package contains provisions for some issues related
|
|
|
|
|
|
to microcode loading. While those provisions are expected to suit most users,
|
|
|
|
|
|
several knobs are available in order to provide ability to override the default
|
|
|
|
|
|
behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
General behaviour
|
|
|
|
|
|
=================
|
|
|
|
|
|
In RHEL 8 (as well as RHEL 7 before it), there are currently two main handlers
|
|
|
|
|
|
for CPU microcode update:
|
|
|
|
|
|
* Early microcode update. It uses GenuineIntel.bin or AuthenticAMD.bin file
|
|
|
|
|
|
placed at the beginning of an initramfs image
|
|
|
|
|
|
(/boot/initramfs-KERNEL_VERSION.img, where "KERNEL_VERSION" is a kernel
|
|
|
|
|
|
version in the same format as provided by "uname -r") as a source
|
|
|
|
|
|
of microcode data, and is performed very early during the boot process
|
|
|
|
|
|
(if the relevant microcode file is available in the aforementioned file).
|
|
|
|
|
|
* On-demand (late) microcode update. It can be triggered by writing "1" to
|
|
|
|
|
|
/sys/devices/system/cpu/microcode/reload file (provided my the "microcode"
|
|
|
|
|
|
module). It relies on request_firmware infrastructure, which searches (and
|
|
|
|
|
|
loads, if found) microcode from a file present in one of the following
|
|
|
|
|
|
directories (in the search order):
|
|
|
|
|
|
/lib/firmware/updates/KERNEL_VERSION/
|
|
|
|
|
|
/lib/firmware/updates/
|
|
|
|
|
|
/lib/firmware/KERNEL_VERSION/
|
|
|
|
|
|
/lib/firmware/
|
|
|
|
|
|
(there is also an additional directory that can be configured via the
|
|
|
|
|
|
"fw_path_para" module option of the "firmware_class" module; as this module
|
|
|
|
|
|
is built-in in RHEL kernel, a boot parameter "firmware_class.fw_path_para"
|
|
|
|
|
|
should be used for that purpose; this is out of the document's scope, however)
|
|
|
|
|
|
|
|
|
|
|
|
The firmware for Intel CPUs is searched in "intel-ucode" subdirectory, and for
|
|
|
|
|
|
AMD CPUs, a file under "amd-ucode" is searched.
|
|
|
|
|
|
|
|
|
|
|
|
For Intel CPUs, the name of the specific microcode file the kernel tries to load
|
|
|
|
|
|
has the format "FF-MM-SS", where "FF" is the family number, "MM" is the model
|
|
|
|
|
|
number, and "SS" is the stepping. All those numbers are zero-filled to two digits
|
|
|
|
|
|
and are written in hexadecimal (letters are in the lower case). For AMD CPUs,
|
|
|
|
|
|
the file name has the format "microcode_amd_famFFh.bin", where "FF" is the
|
|
|
|
|
|
family number, written in hexadecimal, letters are in the lower case, not
|
|
|
|
|
|
zero-filled.
|
|
|
|
|
|
|
|
|
|
|
|
The early microcode is placed into initramfs image by the "dracut" script, which
|
|
|
|
|
|
scans the aforementioned subdirectories of the configured list of firmware
|
|
|
|
|
|
directories (by default, the list consists of two directories in RHEL 8,
|
|
|
|
|
|
"/lib/firmware/updates" and "/lib/firmware").
|
|
|
|
|
|
|
|
|
|
|
|
In RHEL 8, AMD CPU microcode is shipped as a part of the linux-firmware package,
|
|
|
|
|
|
and Intel microcode is shipped as a part of the microcode_ctl package.
|
|
|
|
|
|
|
|
|
|
|
|
The microcode_ctl package currently includes the following:
|
|
|
|
|
|
* Intel CPU microcode files, placed in /usr/share/microcode_ctl/intel-ucode
|
|
|
|
|
|
directory (currently there are none);
|
|
|
|
|
|
* A dracut module, /usr/lib/dracut/modules.d/99microcode_ctl-fw_dir_override,
|
|
|
|
|
|
that controls which additional firmware directories will be added to dracut's
|
|
|
|
|
|
default configuration;
|
|
|
|
|
|
* A dracut configuration file, /usr/lib/dracut/dracut.conf.d/01-microcode.conf,
|
|
|
|
|
|
that enables inclusion of early microcode to the generated initramfs
|
|
|
|
|
|
in dracut;
|
|
|
|
|
|
* A dracut configuration file,
|
|
|
|
|
|
/usr/lib/dracut/dracut.conf.d/99-microcode-override.conf, that provides a way
|
|
|
|
|
|
to quickly disable 99microcode_ctl-fw_dir-override dracut module;
|
|
|
|
|
|
* A systemd service file, microcode.service, that triggers microcode reload
|
|
|
|
|
|
late during boot;
|
|
|
|
|
|
* A set of directories in /usr/share/microcode_ctl/ucode_with_caveats, each
|
|
|
|
|
|
of which contains configuration and related data for various caveats related
|
|
|
|
|
|
to microcode:
|
|
|
|
|
|
* readme - description of caveat and related information,
|
|
|
|
|
|
* config - caveat configuration file, with syntax as described in "Caveat
|
|
|
|
|
|
configuration" section below,
|
|
|
|
|
|
* intel-ucode - directory containing microcode files related to the caveat;
|
|
|
|
|
|
* A set of support scripts, placed in /usr/libexec/microcode_ctl:
|
|
|
|
|
|
* "check_caveats" is an utility script that performs checks of the target
|
|
|
|
|
|
kernel (and running CPU) in accordance with caveat configuration files
|
|
|
|
|
|
in ucode_with_caveats directory and reports whether it passes them or not,
|
|
|
|
|
|
* "reload_microcode" is a script that is called by microcode.service and
|
|
|
|
|
|
triggers microcode reloading (by writing "1" to
|
|
|
|
|
|
/sys/devices/system/cpu/microcode/reload) if the running kernel passes
|
|
|
|
|
|
check_caveats checks,
|
|
|
|
|
|
* "update_ucode" is a script that populates symlinks to microcode files
|
|
|
|
|
|
in /lib/firmware, so it can be picked up by relevant kernels for the late
|
|
|
|
|
|
microcode loading.
|
|
|
|
|
|
|
|
|
|
|
|
Also, microcode_ctl RPM includes triggers that run update_ucode script on every
|
|
|
|
|
|
installation or removal of a kernel RPM in order to provide microcode files
|
|
|
|
|
|
for newly installed kernels and cleanup symlinks for the uninstalled ones.
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-09 00:48:54 +00:00
|
|
|
|
Microcode file structure
|
|
|
|
|
|
------------------------
|
|
|
|
|
|
Intel x86 CPU microcode file (that is, one that can be directly consumed
|
|
|
|
|
|
by the CPU/kernel, and not its text representation such as used in microcode.dat
|
|
|
|
|
|
files) is a bundle of concatenated microcode blobs. Each blob has a header,
|
|
|
|
|
|
payload, and an optional additional data, as follows (for additional information
|
|
|
|
|
|
please refer to "Intel® 64 and IA-32 Architectures Software Developer’s Manual"
|
|
|
|
|
|
[1], Volume 3A, Section 9.11.1 "Microcode Update"):
|
|
|
|
|
|
* Header (48 bytes)
|
|
|
|
|
|
* Header version (unsigned 32-bit integer): version number of the update
|
|
|
|
|
|
header. Must be 0x1.
|
|
|
|
|
|
* Microcode revision (signed 32-bit integer)
|
|
|
|
|
|
* Microcode date (unsigned 32-bit integer): encoded as BCD in mmddyyyy format
|
|
|
|
|
|
(0x03141592 is 1592-03-14 in ISO 8601)
|
|
|
|
|
|
* CPU signature (unsigned 32-bit integer): CPU ID, as provided
|
|
|
|
|
|
by the CPUID (EAX = 0x1) instruction in the EAX register:
|
|
|
|
|
|
* bits 31..28: reserved
|
|
|
|
|
|
* bits 27..20: "Extended Family", summed with the Family field value
|
|
|
|
|
|
* bits 19..16: "Extended Model", bits 7..4 of the CPU model
|
|
|
|
|
|
* bits 15..14: reserved
|
|
|
|
|
|
* bits 13..12: "Processor Type", non-zero value (other than the "primary
|
|
|
|
|
|
processor") so far used only for the Deschutes (Pentium II) CPU family,
|
|
|
|
|
|
with the processor type of 1, to signify it is an Overdrive processor:
|
|
|
|
|
|
CPUID 0x1632.
|
|
|
|
|
|
* bits 11..08: Family, summed with the Extended Family field value
|
|
|
|
|
|
* bits 07..04: Model (bits 3..0)
|
|
|
|
|
|
* bits 03..00: Stepping
|
|
|
|
|
|
In short, microcode file with Family-Model-Stepping of uv-wx-0z corresponds
|
|
|
|
|
|
to CPUID 0x0TUw0Vxz, where uv = TU + V, with V usually being 0xF when
|
|
|
|
|
|
uv >= 16; with Family being 6 on most of recent Intel CPUs this transforms
|
|
|
|
|
|
into 0x000w06xz. Please also refer to README.intel-ucode, section "About
|
|
|
|
|
|
Processor Signature, Family, Model, Stepping and Platform ID"
|
|
|
|
|
|
for additional information.
|
|
|
|
|
|
* Checksum (unsigned 32-bit integer): correct if sum (in base 1 << 32) of all
|
|
|
|
|
|
the 32-bit integers comprising the microcode amounts to 0.
|
|
|
|
|
|
* Loader version (unsigned 32-bit integer): 0x1.
|
|
|
|
|
|
* Platform ID mask (unsigned 32-bit integer): lower 8 bits indicate the set
|
|
|
|
|
|
of possible values of bits 52..50 of MSR 0x17 ("Platform ID"). In old
|
|
|
|
|
|
(up to Pentium II) microcode blobs the mask may be zero.
|
|
|
|
|
|
* Data size (unsigned 32-bit integer): size of the Payload in bytes,
|
|
|
|
|
|
has to be divisible by 4. 0 means 2000.
|
|
|
|
|
|
* Total size (unsigned 32-bit integer): total microcode blob size (including
|
|
|
|
|
|
header and extended header), has to be divisible by 1024. 0 means 2048.
|
|
|
|
|
|
* Reserved (12 bytes).
|
|
|
|
|
|
* Payload
|
|
|
|
|
|
* Additional data (optional, 20 + 12 * n bytes)
|
|
|
|
|
|
* Extended signature table header (20 bytes)
|
|
|
|
|
|
* Extended signature count (unsigned 32-bit integer)
|
|
|
|
|
|
* Checksum (unsigned 32-bit integer): correct if sum (in base 1 << 32)
|
|
|
|
|
|
of all the 32-bit integers comprising the extender signature table
|
|
|
|
|
|
amounts to 0.
|
|
|
|
|
|
* Reserved (12 bytes).
|
|
|
|
|
|
* Extended signature (12 bytes each)
|
|
|
|
|
|
* CPU signature (unsigned 32-bit integer): see the description of the CPU
|
|
|
|
|
|
signature field in the Header above.
|
|
|
|
|
|
* Platform ID mask (unsigned 32-bit integer): see the description
|
|
|
|
|
|
of the Platform ID mask field in the Header above.
|
|
|
|
|
|
* Checksum (unsigned 32-bit integer): correct if sum (in base 1<< 32)
|
|
|
|
|
|
of all the 32-bit integers comprising the Header (with CPU signature
|
|
|
|
|
|
and Platform ID mask fields replaced with the values from this signature)
|
|
|
|
|
|
and the Payload amounts to 0. Note that since External signature table
|
|
|
|
|
|
header has its own checksum, sum of all its 32-bit values amounts to 0,
|
|
|
|
|
|
so the Checksum in the Header and in the Extended signature will be
|
|
|
|
|
|
the same if the values of CPU signature and Platform ID mask fields
|
|
|
|
|
|
are the same,
|
|
|
|
|
|
|
|
|
|
|
|
[1] https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Caveat configuration
|
|
|
|
|
|
--------------------
|
|
|
|
|
|
There is a directory for each caveat under
|
|
|
|
|
|
/usr/share/microcode_ctl/ucode_with_caveats, containing the following files:
|
|
|
|
|
|
* "config", a configuration file for the caveat;
|
|
|
|
|
|
* "readme", that contains description of the caveat;
|
|
|
|
|
|
* set of related associated microcode files.
|
|
|
|
|
|
|
|
|
|
|
|
"config" file is a set of lines each containing option name and its value,
|
|
|
|
|
|
separated by white space. Currently, the following options are supported:
|
|
|
|
|
|
* "model" option, which has format "VENDOR_ID FF-MM-SS", that specifies
|
|
|
|
|
|
to which CPU model the caveat is applicable (check_caveats ignores caveats
|
|
|
|
|
|
with non-matching models if "-m" option is passed to it). Can be set
|
|
|
|
|
|
in the configuration file only once (the last provided value is used).
|
|
|
|
|
|
* "vendor" option specifies CPUs of which vendor (as provided
|
|
|
|
|
|
in the /proc/cpuinfo file) the caveat is applicable to (check_caveats
|
|
|
|
|
|
ignores caveats with non-matching models when it is invoked with "-m"
|
|
|
|
|
|
option). Can be set in the configuration file only once.
|
|
|
|
|
|
* "path" is a glob pattern that specifies set of microcode files associated
|
|
|
|
|
|
with the caveat as a relative path to the caveat directory. This option
|
|
|
|
|
|
is used for populating files in /lib/firmware by update_ucode script and
|
|
|
|
|
|
for matching microcode file when dracut is run in host-only mode
|
|
|
|
|
|
(as in that case it uses only the first directory in firmware directory list
|
|
|
|
|
|
to look for the microcode file applicable to the host CPU). Can be set
|
|
|
|
|
|
in the configuration file multiple times.
|
|
|
|
|
|
* "kernel" is a minimal kernel version that supports proper handling
|
|
|
|
|
|
of the related microcode files during late microcode load. It may be
|
|
|
|
|
|
provided in one of the following formats that affect the way it is compared
|
|
|
|
|
|
to the running kernel version:
|
|
|
|
|
|
* A.B.C (where A, B, and C are decimal numbers), "upstream version". In this
|
|
|
|
|
|
case, simple version comparison against the respective part of the running
|
|
|
|
|
|
kernel version is used, and the running kernel version should be greater
|
|
|
|
|
|
or equal than the version provided in the configuration option in order
|
|
|
|
|
|
for comparison to succeed (that is, the first part, major version number,
|
|
|
|
|
|
of the running kernel version should be greater than the value provided
|
|
|
|
|
|
in the configuration option, or those should be equal and the second part,
|
|
|
|
|
|
minor version number, should be greater than the minor version number
|
|
|
|
|
|
of the kernel version provided in the configuration option, or the first
|
|
|
|
|
|
two parts should be equal and the third part, patch level, should
|
|
|
|
|
|
be greater or equal the patch level of the version in the configuration
|
|
|
|
|
|
option).
|
|
|
|
|
|
* A.B.C-Y (where A, B, C, and Y are decimal numbers), "Y-stream version".
|
|
|
|
|
|
In this case, A.B.C part should be equal, and Y part of the running kernel
|
|
|
|
|
|
version should be greater or equal than the Y part of the configuration
|
|
|
|
|
|
option version in order to satisfy the comparison requirement.
|
|
|
|
|
|
* A.B.C-Y.Z1.Z2 (where A, B, C, Y, Z1, and Z2 are decimal numbers),
|
|
|
|
|
|
"Z-stream version". In this case, A.B.C-Y part should be equal and Z1.Z2
|
|
|
|
|
|
part of the running kernel should be greater or equal than the respective
|
|
|
|
|
|
part of the configuration option version (when compared as a version)
|
|
|
|
|
|
for comparison to succeed.
|
|
|
|
|
|
Kernel version check passed if at least one comparison of the running kernel
|
|
|
|
|
|
version against a kernel version provided in a configuration option
|
|
|
|
|
|
succeeded. The "kernel" configuration option can be provided
|
|
|
|
|
|
in the configuration file multiple times.
|
|
|
|
|
|
* "kernel_early" is a minimal kernel version that supports proper handling
|
|
|
|
|
|
of the related microcode during early microcode load. The format of the
|
|
|
|
|
|
option and its semantics is similar to the "kernel" configuration options.
|
|
|
|
|
|
This option can be provided multiple times as well.
|
|
|
|
|
|
* "mc_min_ver_late" is the minimal version of the currently loaded microcode
|
|
|
|
|
|
on the CPU (as reported in /proc/cpuinfo) that supports late microcode
|
|
|
|
|
|
update. Microcode update will be attempted only if the currently loaded
|
|
|
|
|
|
microcode version is greater or equal the microcode version provided
|
|
|
|
|
|
in the configuration option. Can be set in the configuration file only once.
|
|
|
|
|
|
* "disable" is a way to disable a specific caveat from inside its
|
|
|
|
|
|
configuration. Argument for the argument is a list of stages ("early",
|
|
|
|
|
|
"late") for which the caveat should be disable. The configuration option
|
|
|
|
|
|
can be provided multiple times in a configuration file.
|
|
|
|
|
|
* "pci_config_val" performs check for specific values in selected parts
|
|
|
|
|
|
of configuration space of specified PCI devices. If "-m" option
|
|
|
|
|
|
is not specified, then the actual check is skipped, and the check returns
|
|
|
|
|
|
result in accordance with the provided "mode" option (se below). Check
|
|
|
|
|
|
arguments are a white-space-separated list of "key=value" pairs.
|
|
|
|
|
|
The following keys are supported:
|
|
|
|
|
|
* "domain" - PCI domain number, or "*" (an asterisk) for any domain.
|
|
|
|
|
|
Default is "*".
|
|
|
|
|
|
* "bus" - PCI bus number, or "*" (an asterisk) for any bus. Default is "*".
|
|
|
|
|
|
* "device" - PCI device number, or "*" (an asterisk) for any device.
|
|
|
|
|
|
Default is "*".
|
|
|
|
|
|
* "function" - PCI function number, or "*" (an asterisk) for any function.
|
|
|
|
|
|
Default is "*".
|
|
|
|
|
|
* "vid" - PCI vendor ID, or empty string for any vendor ID. Default
|
|
|
|
|
|
is empty string.
|
|
|
|
|
|
* "did" - PCI device ID, or empty string for any device ID. Default
|
|
|
|
|
|
is empty string.
|
|
|
|
|
|
* "offset" - offset in device's configuration space where the value resides.
|
|
|
|
|
|
Default is 0.
|
|
|
|
|
|
* "size" - field size. Possible values are 1, 2, 4, or 8. Default is 4.
|
|
|
|
|
|
* "mask" - mask applied to the values during the check. Default is 0.
|
|
|
|
|
|
* "val" - comma-separated list of matching values. Default is 0.
|
|
|
|
|
|
* "mode" - check mode, the way matches are interpreted:
|
|
|
|
|
|
* "success-any" - check succeeds if there was at least one match,
|
|
|
|
|
|
otherwise it fails.
|
|
|
|
|
|
* "success-all" - check succeeds if there was at least one device checked
|
|
|
|
|
|
and all the checked devices have matches, otherwise the check fails.
|
|
|
|
|
|
* "fail-any" - check fails if there was at least one match, otherwise
|
|
|
|
|
|
it succeeds.
|
|
|
|
|
|
* "fail-all" - check fails if there was at least one device checked
|
|
|
|
|
|
and all the checked devices have matches, otherwise the check succeeds.
|
|
|
|
|
|
Default is "success-any".
|
|
|
|
|
|
An example of a check:
|
|
|
|
|
|
pci_config_val mode=success-all device=30 function=3 vid=0x8086 did=0x2083 offset=0x84 size=4 mask=0x38 val=0x38,0x18,0x8
|
|
|
|
|
|
It interprets 4 bytes at offset 0x84 of special files "config" under
|
|
|
|
|
|
directories that match glob pattern "/sys/bus/pci/devices/*:*:1e.3"
|
|
|
|
|
|
as an unsigned integer value, applies mask 0x38 (thus selecting bit 5..3
|
|
|
|
|
|
of it) and checks whether it is one of the values 0x38, 0x18, or 0x8 (0b111,
|
|
|
|
|
|
0b011, or 0b001 in bits 5..3, respectively); if there are such files,
|
|
|
|
|
|
and all the checked values in every checked file has matched at least one
|
|
|
|
|
|
of the aforementioned value, then the check is successful, otherwise
|
|
|
|
|
|
it fails (in accordance with "mode=success-all" semantics). This check fails
|
|
|
|
|
|
if "-m" option is not specified.
|
|
|
|
|
|
* "dmi" performs checks for specific values available in DMI sysfs files
|
2021-08-09 09:26:03 +00:00
|
|
|
|
(present under /sys/devices/virtual/dmi/id/). The check (when it is actually
|
|
|
|
|
|
performed; see a not about "no-model-mode" below) fails if one of the files
|
|
|
|
|
|
is not readable. If "-m" option is not specified, then the actual check
|
2020-12-15 15:59:41 +00:00
|
|
|
|
is skipped, and the check returns value in accordance with "no-model-mode"
|
|
|
|
|
|
parameter value (see below). Check arguments are a white-space-separated
|
|
|
|
|
|
list of "key=value" pairs. The following keys are supported:
|
|
|
|
|
|
* "key" - DMI file to check. Value can be one of the following: bios_date,
|
|
|
|
|
|
bios_vendor, bios_version, board_asset_tag, board_name, board_serial,
|
|
|
|
|
|
board_vendor, board_version, chassis_asset_tag, chassis_serial,
|
|
|
|
|
|
chassis_type, chassis_vendor, chassis_version, product_family,
|
|
|
|
|
|
product_name, product_serial, product_uuid, product_version, sys_vendor.
|
|
|
|
|
|
Default is empty string.
|
2021-08-09 09:26:03 +00:00
|
|
|
|
* "val" - a string to match DMI data present in "key" against.
|
|
|
|
|
|
Can be enclosed in single or double quotes. Default is empty string.
|
|
|
|
|
|
* "keyval" - a pair of "key" and "val" values (with semantics described
|
|
|
|
|
|
above), separated with either "=", ":", "!=", or "!:" characters. Enables
|
|
|
|
|
|
providing of multiple key-value pairs by means of supplying multiple
|
|
|
|
|
|
keyval= parameters. The exclamation sign ("!") character in separator
|
|
|
|
|
|
enables negated matching (so, non-equality of the value in DMI "key" file
|
|
|
|
|
|
and the value of "val" is). The match considered successful when all
|
|
|
|
|
|
the key/val (non-)equalities are in effect. This parameter works
|
|
|
|
|
|
in addition to the pair provided in "key" and "val" parameters
|
|
|
|
|
|
(but allows to avoid using them). Default is empty.
|
|
|
|
|
|
* "mode" - check mode, the way successful matches are interpreted:
|
2020-12-15 15:59:41 +00:00
|
|
|
|
* "success-equal" - returns 0 if the value present in the file
|
|
|
|
|
|
with the name supplied via the "key" parameter file under
|
|
|
|
|
|
/sys/devices/virtual/dmi/id/ is equal to the value supplied as a value
|
2021-08-09 09:26:03 +00:00
|
|
|
|
of "val" parameter and all the pairs provided in "keyval" parameters
|
|
|
|
|
|
are equal and non-equal in accordance with their definition,
|
|
|
|
|
|
otherwise 1.
|
|
|
|
|
|
* "fail-equal" - returns 1 if the value present in the file
|
2020-12-15 15:59:41 +00:00
|
|
|
|
with the name supplied via the "key" parameter file under
|
|
|
|
|
|
/sys/devices/virtual/dmi/id/ is equal to the value supplied as a value
|
2021-08-09 09:26:03 +00:00
|
|
|
|
of "val" parameter and all the pairs provided in "keyval" parameters
|
|
|
|
|
|
are equal and non-equal in accordance with their definition,
|
|
|
|
|
|
otherwise 0.
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Default is "success-any".
|
|
|
|
|
|
* "no-model-mode" - return value if model filter ("-m" option)
|
|
|
|
|
|
is not enabled:
|
|
|
|
|
|
* "success" - return 0.
|
|
|
|
|
|
* "fail" - return 1.
|
|
|
|
|
|
Default is "success".
|
|
|
|
|
|
An example of a check:
|
|
|
|
|
|
dmi mode=fail-equal no-model-mode=success key=bios_vendor val="Dell Inc."
|
|
|
|
|
|
It checks file /sys/devices/virtual/dmi/id/bios_vendor and fails if its
|
|
|
|
|
|
content is "Dell Inc." (without quotes). It succeeds if "-m" option
|
|
|
|
|
|
is not enabled.
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Another example:
|
|
|
|
|
|
dmi mode=fail-equal keyval="sys_vendor=Amazon EC2" keyval="product_name=u-18tb1.metal"
|
|
|
|
|
|
dmi mode=fail-equal keyval="sys_vendor=Lenovo" keyval="product_name=ThinkSystem SR950"
|
|
|
|
|
|
It blocks the caveat from using when either both
|
|
|
|
|
|
/sys/devices/virtual/dmi/id/sys_vendor contains the string "Amazon EC2"
|
|
|
|
|
|
and /sys/devices/virtual/dmi/id/product_name contains the string
|
|
|
|
|
|
"u-18tb1.metal" or both /sys/devices/virtual/dmi/id/sys_vendor contains
|
|
|
|
|
|
the string "Lenovo" and /sys/devices/virtual/dmi/id/product_name contains
|
|
|
|
|
|
the string "ThinkSystem SR950", but enables caveat loading for other products
|
|
|
|
|
|
with the aforementioned /sys/devices/virtual/dmi/id/sys_vendor values,
|
|
|
|
|
|
for example.
|
|
|
|
|
|
* "dependency" allows conditional enablement of a caveat based on the check
|
|
|
|
|
|
status of some other caveat(s). It has the following format:
|
|
|
|
|
|
dependency DEPENDENCY_TYPE DEPENDENCY_NAME [OPTION...]
|
|
|
|
|
|
where DEPENDENCY_NAME is the configuration to be checked, OPTIONs
|
|
|
|
|
|
are per-DEPENDENCY_TYPE, and the only DEPENDENCY_TYPE that is supported
|
|
|
|
|
|
currently is "required".
|
|
|
|
|
|
Options for the "required" dependency type:
|
|
|
|
|
|
* "match-model-mode" - whether model matching mode ("-m" option)
|
|
|
|
|
|
has to be used for the nested configuration check. Possible values:
|
|
|
|
|
|
* "on" - model-matching mode is always used during the nested check;
|
|
|
|
|
|
* "off" - model-matching mode is never used during the nested check;
|
|
|
|
|
|
* "same" - used the same model-matching mode as it is now.
|
|
|
|
|
|
Default is "same".
|
|
|
|
|
|
* "skip" - controls result of the check when the nested check indicated
|
|
|
|
|
|
skipping of the configuration.
|
|
|
|
|
|
* "fail" - the dependent check fails;
|
|
|
|
|
|
* "success" - the dependent check succeeds;
|
|
|
|
|
|
* "skip" - the dependent check indicates that the configuration
|
|
|
|
|
|
is to be skipped.
|
|
|
|
|
|
Default is "skip".
|
|
|
|
|
|
* "force-skip" - controls result of the check when the nested check
|
|
|
|
|
|
indicated skipping of the configuration caused by the presence
|
|
|
|
|
|
of an override file (see "check_caveats script" section for details).
|
|
|
|
|
|
* "fail" - the dependent check fails;
|
|
|
|
|
|
* "success" - the dependent check succeeds;
|
|
|
|
|
|
* "skip" - the dependent check indicates that the configuration
|
|
|
|
|
|
is to be skipped.
|
|
|
|
|
|
Default is "skip".
|
|
|
|
|
|
* "nesting-too-deep" - as a measure against dependency loop, configuration
|
|
|
|
|
|
checking logic implements nesting limit on dependency checks (currently
|
|
|
|
|
|
set at 8). This option controls the behaviour of the check
|
|
|
|
|
|
when the nested check cannot be performed due to this limit.
|
|
|
|
|
|
* "fail" - the dependent check fails;
|
|
|
|
|
|
* "success" - the dependent check succeeds;
|
|
|
|
|
|
* "skip" - the dependent check indicates that the configuration
|
|
|
|
|
|
is to be skipped.
|
|
|
|
|
|
Default is "fail".
|
|
|
|
|
|
An example of a check:
|
|
|
|
|
|
dependency required intel skip=success match-model-mode=off
|
|
|
|
|
|
It checks "intel" caveat configuration (see the "Early microcode load
|
|
|
|
|
|
inside a virtual machine" section) with model-matching mode being disabled,
|
|
|
|
|
|
treats skipping of the configuration as a success (unless the configuration
|
|
|
|
|
|
is forced to be skipped, in that case the dependent configuration
|
|
|
|
|
|
is to be skipped as well).
|
2020-12-15 15:59:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
check_caveats script
|
|
|
|
|
|
--------------------
|
|
|
|
|
|
"check_caveats" is an utility script (called by update_ucode, reload_microcode,
|
|
|
|
|
|
dracut module) that performs checks of the target kernel (and running CPU)
|
|
|
|
|
|
in accordance with caveat configuration files in directory
|
|
|
|
|
|
"/usr/share/microcode_ctl/ucode_with_caveats", and returns information, whether
|
|
|
|
|
|
the system passes the checks, or not.
|
|
|
|
|
|
|
|
|
|
|
|
Usage:
|
|
|
|
|
|
check_caveats [-e] [-k TARGET_KVER] [-c CONFIG]* [-m] [-v]'
|
|
|
|
|
|
|
|
|
|
|
|
Options:
|
|
|
|
|
|
-e - check for early microcode load possibility (instead of late microcode
|
|
|
|
|
|
load). "kernel_early" caveat configuration options are used for checking
|
|
|
|
|
|
instead of "kernel", and "mc_min_ver_late" is not checked.
|
|
|
|
|
|
-k - target kernel version to check against, $(uname -r) is used otherwise.
|
|
|
|
|
|
-c - caveat(s) to check, all caveat configurations found inside
|
|
|
|
|
|
$MC_CAVEATS_DATA_DIR are checked otherwise.
|
|
|
|
|
|
-m - ignore caveats that do not apply to the current CPU model.
|
|
|
|
|
|
-v - verbose output.
|
|
|
|
|
|
|
|
|
|
|
|
Environment:
|
|
|
|
|
|
MC_CAVEATS_DATA_DIR - directory that contains caveats configurations,
|
|
|
|
|
|
"/usr/share/microcode_ctl/ucode_with_caveats"
|
|
|
|
|
|
by default.
|
|
|
|
|
|
FW_DIR - directory containing firmware files (per-kernel configuration
|
|
|
|
|
|
overrides are checked there), "/lib/firmware" by default.
|
|
|
|
|
|
CFG_DIR - directory containing global caveats overrides,
|
|
|
|
|
|
"/etc/microcode_ctl/ucode_with_caveats" by default.
|
|
|
|
|
|
|
|
|
|
|
|
Output:
|
|
|
|
|
|
Script returns information about caveats check results. Output has a format
|
|
|
|
|
|
of "KEY VALUE1 VALUE2 ..." with KEY defining the semantics of the VALUEs.
|
|
|
|
|
|
Currently, the following data is issued:
|
|
|
|
|
|
- "cfgs" - list of caveats that have been processed (and not skipped
|
|
|
|
|
|
due to missing "config", "readme", or a disallow-* override described
|
|
|
|
|
|
below);
|
|
|
|
|
|
- "skip_cfgs" - list of caveats that have been skipped (due to missing
|
|
|
|
|
|
config/readme file, or because of overrides);
|
|
|
|
|
|
- "paths" - list of glob patterns matching files associated with caveats
|
|
|
|
|
|
that have been processed;
|
|
|
|
|
|
- "ok_cfgs" - list of caveat configurations that have all the checks passed
|
|
|
|
|
|
(or have enforced by one of force-* overrides described below);
|
|
|
|
|
|
- "ok_paths" - list of glob patterns associated with caveat files from
|
|
|
|
|
|
the "ok_cfgs" list;
|
|
|
|
|
|
- "fail_cfgs" - list of caveats that have one of the checks failed.
|
|
|
|
|
|
- "fail_paths" - list of glob patterns associated with caveats from the
|
|
|
|
|
|
"fail_cfgs" list.
|
|
|
|
|
|
|
|
|
|
|
|
Return value:
|
|
|
|
|
|
- 0 in case caveats check has passed, 1 otherwise.
|
|
|
|
|
|
- In "-d" mode, 0 is always returned.
|
|
|
|
|
|
|
|
|
|
|
|
Overrides:
|
|
|
|
|
|
|
|
|
|
|
|
When check_caveats perform its checks, it also checks for presence of files
|
|
|
|
|
|
in specific places, and, if they exist, check_caveats skips a caveat or ignores
|
|
|
|
|
|
its checks; that mechanism allows overriding the information provided
|
|
|
|
|
|
in configuration on local systems and affect the behaviour of the microcode
|
|
|
|
|
|
update process.
|
|
|
|
|
|
|
|
|
|
|
|
Current list of overrides (where $FW_DIR and $CFG_DIR are the environment
|
|
|
|
|
|
options described earlier; $kver - the currently processed kernel version,
|
|
|
|
|
|
$s is the requested stage ("early" or "late"), $cfg is the caveat directory
|
|
|
|
|
|
name):
|
|
|
|
|
|
$FW_DIR/$kver/disallow-$s-$cfg - skip a caveat for the requested stage for
|
|
|
|
|
|
a specific kernel version..
|
|
|
|
|
|
$FW_DIR/$kver/force-$s-$cfg - apply a specific caveat file for a specific
|
|
|
|
|
|
kernel version for the requested stage without
|
|
|
|
|
|
performing any checks.
|
|
|
|
|
|
$FW_DIR/$kver/disallow-$cfg - skip a caveat for any stage for a specific
|
|
|
|
|
|
kernel version.
|
|
|
|
|
|
$FW_DIR/$kver/force-$cfg - apply a specific caveat for any stage
|
|
|
|
|
|
for a specific kernel version without checks.
|
|
|
|
|
|
$FW_DIR/$kver/disallow-$s - skip all caveats for a specific stage
|
|
|
|
|
|
for a specific kernel version.
|
|
|
|
|
|
$CFG_DIR/disallow-$s-$cfg - skip a caveat for a specific stage for all
|
|
|
|
|
|
kernel versions.
|
|
|
|
|
|
$FW_DIR/$kver/force-$s - apply all caveats for a specific stage
|
|
|
|
|
|
for a specific kernel version without checks.
|
|
|
|
|
|
$CFG_DIR/force-$s-$cfg - apply a specific caveat for a specific stage for
|
|
|
|
|
|
all kernel versions without checks.
|
|
|
|
|
|
$FW_DIR/$kver/disallow - skip all caveats for all stages for a specific
|
|
|
|
|
|
kernel version.
|
|
|
|
|
|
$CFG_DIR/disallow-$cfg - skip a caveat for all stages for all kernel
|
|
|
|
|
|
versions.
|
|
|
|
|
|
$FW_DIR/$kver/force - apply all caveats for all stages for a specific kernel
|
|
|
|
|
|
version without checks.
|
|
|
|
|
|
$CFG_DIR/force-$cfg - apply a caveat for all stages for all kernel versions
|
|
|
|
|
|
without checks.
|
|
|
|
|
|
$CFG_DIR/disallow-$s - skip all caveat for all kernel versions
|
|
|
|
|
|
for a specific stage.
|
|
|
|
|
|
$CFG_DIR/force-$s - apply all caveats for all kernel versions for specific
|
|
|
|
|
|
stage without checks.
|
|
|
|
|
|
$CFG_DIR/disallow - skip all caveats for all stages for all kernel versions
|
|
|
|
|
|
(disable everything).
|
|
|
|
|
|
$CFG_DIR/force - force all caveats for all stages for all kernel versions
|
|
|
|
|
|
(enable everything).
|
|
|
|
|
|
|
|
|
|
|
|
The "apply" action above means creating symlinks in /lib/firmware by
|
|
|
|
|
|
update_ucode in case of the "late" stage and adding caveat directory to the list
|
|
|
|
|
|
of firmware directories by dracut plugin in case of the "early" stage.
|
|
|
|
|
|
|
|
|
|
|
|
The files are checked for existence until the first match, so more specific
|
|
|
|
|
|
overrides can override more broad ones.
|
|
|
|
|
|
|
|
|
|
|
|
Also, a caveat is ignored if it lacks either config or readme file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
update_ucode script
|
|
|
|
|
|
-------------------
|
|
|
|
|
|
"update_ucode" populates symlinks to microcode files in accordance with caveats
|
|
|
|
|
|
configuration. It enables late microcode loading that is invoked by triggering
|
|
|
|
|
|
/sys/devices/system/cpu/microcode/reload file. Since caveats depend
|
|
|
|
|
|
on the kernel version, symlinks are populated inside
|
|
|
|
|
|
"/lib/firmware/KERNEL_VERSION" directory for each installed kernel.
|
|
|
|
|
|
As a consequence, this script is triggered upon each kernel package installation
|
|
|
|
|
|
and removal.
|
|
|
|
|
|
|
|
|
|
|
|
The script has two parts: common and kernel-version-specific.
|
|
|
|
|
|
|
|
|
|
|
|
During the common part, files are populated from
|
|
|
|
|
|
/usr/share/microcode_ctl/intel-ucode in /lib/firmware/intel-ucode. There are
|
|
|
|
|
|
several possibilities to affect the process:
|
|
|
|
|
|
* Presence of "/etc/microcode_ctl/intel-ucode-disallow" file leads to skipping
|
|
|
|
|
|
the common part of the script.
|
|
|
|
|
|
* The same for "/lib/firmware/intel-ucode-disallow".
|
|
|
|
|
|
|
|
|
|
|
|
During the kernel-version-specific part, each caveat is checked against every
|
|
|
|
|
|
kernel version, and those combinations, for which caveat check succeeds,
|
|
|
|
|
|
gets the symlinks to the associated microcode files populated.
|
|
|
|
|
|
* Absence of "/lib/firmware/KERNEL_VERSION/readme-CAVEAT" prevents update_ucode
|
|
|
|
|
|
from removing symlinks related to the caveat for specific kernel version.
|
|
|
|
|
|
* Since the check is being done by check_caveats, all the overrides that
|
|
|
|
|
|
described there also stay.
|
|
|
|
|
|
|
|
|
|
|
|
Usage:
|
|
|
|
|
|
update_ucode [--action {add|remove|refresh|list}] [--kernel KERNELVER]*
|
|
|
|
|
|
[--verbose] [--dry-run] [--cleanup intel_ucode caveats_ucode]
|
|
|
|
|
|
[--skip-common] [--skip-kernel-specific]
|
|
|
|
|
|
|
|
|
|
|
|
Options:
|
|
|
|
|
|
--action - action to perform. Currently, the following actions are supported:
|
|
|
|
|
|
* "add" - create new symlinks.
|
|
|
|
|
|
* "remove" - remove old symlinks that are no longer needed.
|
|
|
|
|
|
* "refresh" - re-populate symlinks.
|
|
|
|
|
|
* "list" - list files under control of update_ucode.
|
|
|
|
|
|
By default, "refresh" action is executed.
|
|
|
|
|
|
--kernel - kernel version to process. By default, list of kernel versions
|
|
|
|
|
|
is formed based on contents of /lib/firmware and /lib/modules
|
|
|
|
|
|
directories.
|
|
|
|
|
|
--verbose - verbose output.
|
|
|
|
|
|
--dry-run - do not call commands, just print the invocation lines.
|
|
|
|
|
|
--cleanup - cleanup mode. Used by post-uninstall script during package
|
|
|
|
|
|
upgrades. Removes excess files in accordance to the contents
|
|
|
|
|
|
of the files provided in the arguments to the option.
|
|
|
|
|
|
--skip-common - do not process /lib/firmware directory.
|
|
|
|
|
|
--skip-kernel-specific - do not process /lib/firmware/KERNEL_VERSION
|
|
|
|
|
|
directories.
|
|
|
|
|
|
|
|
|
|
|
|
Return value:
|
|
|
|
|
|
0 on success, 1 on error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
reload_microcode script
|
|
|
|
|
|
-----------------------
|
|
|
|
|
|
"reload_microcode" is a script that is called by microcode.service and
|
|
|
|
|
|
triggers late microcode reloading (by writing "1" to
|
|
|
|
|
|
/sys/devices/system/cpu/microcode/reload) if the following check are passed:
|
|
|
|
|
|
* the microcode update performed not in a virtualised environment;
|
|
|
|
|
|
* running kernel passes "check_caveats" checks that applicable to the current
|
|
|
|
|
|
CPU model.
|
|
|
|
|
|
|
|
|
|
|
|
For a virtualised environment check, the script searches the "/proc/cpuinfo"
|
|
|
|
|
|
file for presence of the "hypervisor" flag among CPU features (it corresponds
|
|
|
|
|
|
to a CPUID feature bit set by hypervisors in order to inform that the kernel
|
|
|
|
|
|
operates inside a virtual machine). This check can be overridden and skipped
|
|
|
|
|
|
by creation of a file "/etc/microcode_ctl/ignore-hypervisor-flag".
|
|
|
|
|
|
|
|
|
|
|
|
The script has no options and always returns 0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
99microcode_ctl-fw_dir_override dracut module
|
|
|
|
|
|
---------------------------------------------
|
|
|
|
|
|
This dracut module injects directories with microcode files for caveats
|
|
|
|
|
|
that pass "early" check_caveats check (with "-e" flag). In addition
|
|
|
|
|
|
to "check_caveats" overrides, the following abilities to control module's
|
|
|
|
|
|
behaviour are present:
|
|
|
|
|
|
* Presence of one of the following files:
|
|
|
|
|
|
- /etc/microcode_ctl/ucode_with_caveats/skip-host-only-check
|
|
|
|
|
|
- /etc/microcode_ctl/ucode_with_caveats/skip-host-only-check-$cfg
|
|
|
|
|
|
- /lib/firmware/$kver/skip-host-only-check
|
|
|
|
|
|
- /lib/firmware/$kver/skip-host-only-check-$cfg
|
|
|
|
|
|
(where "$kver" is the kernel version in question and "$cfg" is the caveat
|
|
|
|
|
|
directory name) allows skipping matching of microcode file name when dracut's
|
|
|
|
|
|
Host-Only mode is enabled.
|
|
|
|
|
|
|
|
|
|
|
|
When caveats_check succeeds, caveats directory (not its possibly populated
|
|
|
|
|
|
version for late microcode update: "/lib/firmware/KERNEL_VERSION";
|
|
|
|
|
|
it is done so in order
|
|
|
|
|
|
to have ability to configure list of caveats enabled for early and late
|
|
|
|
|
|
microcode update, independently) is added to dracut's list of firmware search
|
|
|
|
|
|
directories.
|
|
|
|
|
|
|
|
|
|
|
|
The module can be disabled by running dracut with
|
|
|
|
|
|
"-o microcode_ctl-fw_dir_override" (for one-time exclusion), or it can
|
|
|
|
|
|
be disabled permanently by uncommenting string
|
|
|
|
|
|
"omit_dracutmodules+=' microcode_ctl-fw_dir_override '" in
|
|
|
|
|
|
/usr/lib/dracut/dracut.conf.d/99-microcode-override.conf configuration file.
|
|
|
|
|
|
|
|
|
|
|
|
See dracut(8), section "Omitting dracut Modules", and dracut.conf(5), variable
|
|
|
|
|
|
"omit_dracutmodules" for additional information.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Caveats
|
|
|
|
|
|
=======
|
|
|
|
|
|
|
|
|
|
|
|
Intel Broadwell-EP/EX ("BDX-ML B/M/R0") caveat
|
|
|
|
|
|
----------------------------------------------
|
|
|
|
|
|
Microcode update process on Intel Broadwell-EP/EX CPUs (BDX-ML B/M/R0,
|
|
|
|
|
|
family 6, model 79, stepping 1) has issues that lead to system instability.
|
|
|
|
|
|
A series of changes for the Linux kernel has been developed in order to work
|
|
|
|
|
|
around those issues; however, as it turned out, some systems have issues even
|
|
|
|
|
|
when a microcode update performed on a kernel that contains those changes.
|
|
|
|
|
|
As a result, microcode update for this CPU model is disabled by default;
|
|
|
|
|
|
the microcode file, however, is still shipped as a part of microcode_ctl
|
|
|
|
|
|
package and can be used for performing a microcode update if it is enforced
|
|
|
|
|
|
via the aforementioned overrides. (See the sections "check_caveats script"
|
|
|
|
|
|
and "reload_microcode script" for details.)
|
|
|
|
|
|
|
|
|
|
|
|
Caveat name: intel-06-4f-01
|
|
|
|
|
|
|
|
|
|
|
|
Affected microcode: intel-ucode/06-4f-01.
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Dependencies: intel
|
|
|
|
|
|
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Mitigation: microcode loading is disabled for the affected CPU model.
|
|
|
|
|
|
|
|
|
|
|
|
Minimum versions of the kernel package that contain the aforementioned patch
|
|
|
|
|
|
series:
|
|
|
|
|
|
- Upstream/RHEL 8: 4.17.0
|
|
|
|
|
|
- RHEL 7.6 onwards: 3.10.0-894
|
|
|
|
|
|
- RHEL 7.5: 3.10.0-862.6.1
|
|
|
|
|
|
- RHEL 7.4: 3.10.0-693.35.1
|
|
|
|
|
|
- RHEL 7.3: 3.10.0-514.52.1
|
|
|
|
|
|
- RHEL 7.2: 3.10.0-327.70.1
|
|
|
|
|
|
- RHEL 6.10: 2.6.32-754.1.1
|
|
|
|
|
|
- RHEL 6.7: 2.6.32-573.58.1
|
|
|
|
|
|
- RHEL 6.6: 2.6.32-504.71.1
|
|
|
|
|
|
- RHEL 6.5: 2.6.32-431.90.1
|
|
|
|
|
|
- RHEL 6.4: 2.6.32-358.90.1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Early microcode load inside a virtual machine
|
|
|
|
|
|
---------------------------------------------
|
|
|
|
|
|
RHEL 8 kernel supports performing microcode update during early boot stage
|
|
|
|
|
|
from a cpio archive placed at the beginning of the initramfs image. However,
|
|
|
|
|
|
when an early microcode update is attempted inside some virtualised
|
|
|
|
|
|
environments, that may result in unexpected system behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
Caveat name: intel
|
|
|
|
|
|
|
|
|
|
|
|
Affected microcode: all.
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Dependencies: (none)
|
|
|
|
|
|
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Mitigation: early microcode loading is disabled for all CPU models on kernels
|
|
|
|
|
|
without the fix.
|
|
|
|
|
|
|
|
|
|
|
|
Minimum versions of the kernel package that contain the fix:
|
|
|
|
|
|
- Upstream/RHEL 8: 4.10.0
|
|
|
|
|
|
- RHEL 7.6 onwards: 3.10.0-930
|
|
|
|
|
|
- RHEL 7.5: 3.10.0-862.14.1
|
|
|
|
|
|
- RHEL 7.4: 3.10.0-693.38.1
|
|
|
|
|
|
- RHEL 7.3: 3.10.0-514.57.1
|
|
|
|
|
|
- RHEL 7.2: 3.10.0-327.73.1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Intel Sandy Bridge-E/EN/EP caveat
|
|
|
|
|
|
---------------------------------
|
|
|
|
|
|
Microcode revision 0x718 for Intel Sandy Bridge-E/EN/EP (SNB-EP, family 6,
|
|
|
|
|
|
model 45, stepping 7), that was released to address MDS vulnerability,
|
|
|
|
|
|
and was available from microcode-20190618 up to microcode-20190508 release)
|
|
|
|
|
|
could lead to system instability[1][2]. In order to address this,
|
|
|
|
|
|
this microcode update was not used and the previous microcode revision
|
|
|
|
|
|
was provided instead by default; the microcode file, however, was still shipped
|
|
|
|
|
|
as part of microcode_ctl package and could be used for performing a microcode
|
|
|
|
|
|
update if it is enforced via the aforementioned overrides. With the release
|
|
|
|
|
|
of 0x71a revision of the microcode (as art of microcode-20200520 release)
|
|
|
|
|
|
that aims at fixing the aforementioned stability issue, the latest microcode
|
|
|
|
|
|
revision is again used by default; it is still provided via the caveat
|
|
|
|
|
|
mechanism, hovewer, in order to enable ability to disable it in case such
|
|
|
|
|
|
a need arises. (See the sections "check_caveats script" and "reload_microcode
|
|
|
|
|
|
script" for details regarding caveats mechanism operation.)
|
|
|
|
|
|
|
|
|
|
|
|
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/15
|
|
|
|
|
|
[2] https://access.redhat.com/solutions/4593951
|
|
|
|
|
|
|
|
|
|
|
|
Caveat name: intel-06-2d-07
|
|
|
|
|
|
|
|
|
|
|
|
Affected microcode: intel-ucode/06-2d-07.
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Dependencies: intel
|
|
|
|
|
|
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Mitigation: None; the latest revision of the microcode file is used by default;
|
|
|
|
|
|
previously published microcode revision 0x714 is still available as a fallback
|
|
|
|
|
|
as part of "intel" caveat.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Intel Skylake-SP/W/X caveat
|
|
|
|
|
|
---------------------------
|
|
|
|
|
|
Microcode revision 0x2000065 (that was provided with microcode releases
|
|
|
|
|
|
microcode-20191112 up to microcode-20200520) for some CPU models that belong
|
|
|
|
|
|
to Intel Skylake Scalable Platform (SKL-W/X, family 6, model 85, stepping 4,
|
|
|
|
|
|
Workstation/HEDT segments) could lead to hangs during reboot[1]. In order
|
|
|
|
|
|
to address this, by default this microcode update was disabled by default and
|
|
|
|
|
|
and the previous 0x2000064 microcode revision was used instead; the microcode
|
|
|
|
|
|
file with, however, is still shipped as part of microcode_ctl package and can
|
|
|
|
|
|
be used for performing a microcode update if it is enforced
|
|
|
|
|
|
via the aforementioned overrides. With the availability of 0x2006906 revision
|
|
|
|
|
|
of the microcode (in the microcode-20200609 release) that fixes
|
|
|
|
|
|
the aforementioned issue, the latest microcode revision is again used
|
|
|
|
|
|
by default; it is still provided via caveat mechanism, hovewer, in order
|
|
|
|
|
|
to enable ability to disable it in case such a need arises. (See the sections
|
|
|
|
|
|
"check_caveats script" and "reload_microcode script" for details regarding
|
|
|
|
|
|
caveats mechanism operation.)
|
|
|
|
|
|
|
|
|
|
|
|
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/21
|
|
|
|
|
|
|
|
|
|
|
|
Caveat name: intel-06-55-04
|
|
|
|
|
|
|
|
|
|
|
|
Affected microcode: intel-ucode/06-55-04.
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Dependencies: intel
|
|
|
|
|
|
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Mitigation: None; the latest revision of the microcode file is used by default;
|
|
|
|
|
|
previously published microcode revision 0x2000064 is still available
|
|
|
|
|
|
as a fallback as part of "intel" caveat.
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Intel Skylake-U/Y caveat
|
|
|
|
|
|
------------------------
|
|
|
|
|
|
Some Intel Skylake CPU models (SKL-U/Y, family 6, model 78, stepping 3)
|
|
|
|
|
|
have reports of system hangs when revision 0xdc of microcode, that is included
|
|
|
|
|
|
in microcode-20200609 update to address CVE-2020-0543, CVE-2020-0548,
|
|
|
|
|
|
and CVE-2020-0549, is applied[1]. In order to address this, microcode update
|
|
|
|
|
|
to the newer revision has been disabled by default on these systems,
|
|
|
|
|
|
and the previously published microcode revision 0xd6 is used instead; the newer
|
|
|
|
|
|
microcode files, however, are still shipped as part of microcode_ctl package
|
|
|
|
|
|
and can be used for performing a microcode update if they are enforced
|
|
|
|
|
|
via the aforementioned overrides. (See the sections "check_caveats script"
|
|
|
|
|
|
and "reload_microcode script" for details.)
|
2020-12-15 15:59:41 +00:00
|
|
|
|
|
|
|
|
|
|
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Caveat name: intel-06-4e-03
|
2020-12-15 15:59:41 +00:00
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Affected microcode: intel-ucode/06-4e-03
|
|
|
|
|
|
|
|
|
|
|
|
Dependencies: intel
|
2020-12-15 15:59:41 +00:00
|
|
|
|
|
|
|
|
|
|
Mitigation: previously published microcode revision 0xd6 is used by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Intel Skylake-H/S/Xeon E3 v5 caveat
|
|
|
|
|
|
-----------------------------------
|
|
|
|
|
|
Some Intel Skylake CPU models (SKL-H/S/Xeon E3 v5, family 6, model 94,
|
|
|
|
|
|
stepping 3) had reports of system hangs when revision 0xdc of microcode,
|
|
|
|
|
|
that is included in microcode-20200609 update to address CVE-2020-0543,
|
|
|
|
|
|
CVE-2020-0548, and CVE-2020-0549, was applied[1]. In order to address this,
|
|
|
|
|
|
microcode update to the newer revision had been disabled by default on these
|
|
|
|
|
|
systems, and the previously published microcode revision 0xd6 was used instead.
|
|
|
|
|
|
The revision 0xea seems[2] to have fixed the aforementioned issue, hence
|
|
|
|
|
|
the latest microcode revision usage it is enabled by default,
|
|
|
|
|
|
but can be disabled explicitly via the aforementioned overrides. (See
|
|
|
|
|
|
the sections "check_caveats script" and "reload_microcode script" for details.)
|
|
|
|
|
|
|
|
|
|
|
|
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-644885826
|
|
|
|
|
|
[2] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-857806014
|
|
|
|
|
|
|
|
|
|
|
|
Caveat names: intel-06-5e-03
|
|
|
|
|
|
|
|
|
|
|
|
Affected microcode: intel-ucode/06-5e-03.
|
|
|
|
|
|
|
|
|
|
|
|
Dependencies: intel
|
|
|
|
|
|
|
|
|
|
|
|
Mitigation: None; the latest revision of the microcode file is used by default;
|
|
|
|
|
|
previously published microcode revision 0xd6 is still available as a fallback
|
|
|
|
|
|
as part of "intel" caveat.
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Dell caveats
|
|
|
|
|
|
------------
|
|
|
|
|
|
Some Dell systems that use some models of Intel CPUs are susceptible to hangs
|
|
|
|
|
|
and system instability during or after microcode update to revision 0xc6/0xca
|
|
|
|
|
|
(included as part of microcode-20191113/microcode-20191115 update that addressed
|
|
|
|
|
|
CVE-2019-0117, CVE-2019-0123, CVE-2019-11135, and CVE-2019-11139)
|
|
|
|
|
|
and/or revision 0xd6 (included as part of microcode-20200609 update
|
|
|
|
|
|
that addressed CVE-2020-0543, CVE-2020-0548, and CVE-2020-0549)
|
|
|
|
|
|
[1][2][3][4][5][6]. In order to address this, microcode update to the newer
|
|
|
|
|
|
revision has been disabled by default on these systems, and the previously
|
|
|
|
|
|
published microcode revisions 0xae/0xb4/0xb8 are used by default
|
|
|
|
|
|
for the OS-driven microcode update.
|
|
|
|
|
|
|
|
|
|
|
|
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/23
|
|
|
|
|
|
[2] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/24
|
|
|
|
|
|
[3] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/33
|
|
|
|
|
|
[4] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/34
|
|
|
|
|
|
[5] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/35
|
|
|
|
|
|
[6] https://bugzilla.redhat.com/show_bug.cgi?id=1846097
|
|
|
|
|
|
|
|
|
|
|
|
Caveat names: intel-06-8e-9e-0x-dell, intel-06-8e-9e-0x-0xca
|
|
|
|
|
|
|
|
|
|
|
|
Affected microcode: intel-ucode/06-8e-09, intel-ucode/06-8e-0a,
|
|
|
|
|
|
intel-ucode/06-8e-0b, intel-ucode/06-8e-0c,
|
|
|
|
|
|
intel-ucode/06-9e-09, intel-ucode/06-9e-0a,
|
|
|
|
|
|
intel-ucode/06-9e-0b, intel-ucode/06-9e-0c,
|
|
|
|
|
|
intel-ucode/06-9e-0d.
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Dependencies: intel
|
|
|
|
|
|
|
2020-12-15 15:59:41 +00:00
|
|
|
|
Mitigation: previously published microcode revision 0xac/0xb4/0xb8 is used
|
|
|
|
|
|
by default if /sys/devices/virtual/dmi/id/bios_vendor reports
|
|
|
|
|
|
"Dell Inc."; otherwise, the latest microcode revision is used.
|
|
|
|
|
|
Caveat with revision 0xca of microcode files is provided
|
|
|
|
|
|
as a convenience for the cases where it was working well before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Intel Tiger Lake-UP3/UP4 caveat
|
|
|
|
|
|
-------------------------------
|
|
|
|
|
|
Some systems with Intel Tiger Lake-UP3/UP4 CPUs (TGL, family 6, model 140,
|
2021-08-09 09:26:03 +00:00
|
|
|
|
stepping 1) had reports of system hangs when a microcode update,
|
|
|
|
|
|
that was included since microcode-20201110 release, was applied[1].
|
|
|
|
|
|
In order to address this, microcode update to a newer revision had been disabled
|
|
|
|
|
|
by default on these systems. The revision 0x88 seems to have fixed
|
|
|
|
|
|
the aforementioned issue, hence it is enabled by default; however, it is still
|
|
|
|
|
|
can be disabled via the aforementioned overrides. (See the sections
|
2020-12-15 15:59:41 +00:00
|
|
|
|
"check_caveats script" and "reload_microcode script" for details.)
|
|
|
|
|
|
|
|
|
|
|
|
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/44
|
|
|
|
|
|
|
|
|
|
|
|
Caveat names: intel-06-8c-01
|
|
|
|
|
|
|
|
|
|
|
|
Affected microcode: intel-ucode/06-8c-01.
|
|
|
|
|
|
|
2021-08-09 09:26:03 +00:00
|
|
|
|
Dependencies: intel
|
|
|
|
|
|
|
|
|
|
|
|
Mitigation: None; the latest revision of the microcode file is used by default.
|
2020-12-15 15:59:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Additional information
|
|
|
|
|
|
======================
|
|
|
|
|
|
Red Hat provides updated microcode, developed by its microprocessor partners,
|
|
|
|
|
|
as a customer convenience. Please contact your hardware vendor to determine
|
|
|
|
|
|
whether more recent BIOS/firmware updates are recommended because additional
|
|
|
|
|
|
improvements may be available.
|
|
|
|
|
|
|
|
|
|
|
|
Information regarding microcode revisions required for mitigating specific
|
|
|
|
|
|
Intel CPU vulnerabilities is available in the following knowledge base articles:
|
|
|
|
|
|
* CVE-2017-5715 ("Spectre"):
|
|
|
|
|
|
https://access.redhat.com/articles/3436091
|
|
|
|
|
|
* CVE-2018-3639 ("Speculative Store Bypass"):
|
|
|
|
|
|
https://access.redhat.com/articles/3540901
|
|
|
|
|
|
* CVE-2018-3620, CVE-2018-3646 ("L1 Terminal Fault Attack"):
|
|
|
|
|
|
https://access.redhat.com/articles/3562741
|
|
|
|
|
|
* CVE-2018-12130, CVE-2018-12126, CVE-2018-12127, and CVE-2019-11091
|
|
|
|
|
|
("Microarchitectural Data Sampling"):
|
|
|
|
|
|
https://access.redhat.com/articles/4138151
|
|
|
|
|
|
* CVE-2019-0117 (Intel SGX Information Leak),
|
|
|
|
|
|
CVE-2019-0123 (Intel SGX Privilege Escalation),
|
|
|
|
|
|
CVE-2019-11135 (TSX Asynchronous Abort),
|
|
|
|
|
|
CVE-2019-11139 (Voltage Setting Modulation):
|
|
|
|
|
|
https://access.redhat.com/solutions/2019-microcode-nov
|
|
|
|
|
|
* CVE-2020-0543 (Special Register Buffer Data Sampling),
|
|
|
|
|
|
CVE-2020-0548 (Vector Register Data Sampling),
|
|
|
|
|
|
CVE-2020-0549 (L1D Cache Eviction Sampling):
|
|
|
|
|
|
https://access.redhat.com/solutions/5142751
|
|
|
|
|
|
* CVE-2020-8695 (Information disclosure issue in Intel SGX via RAPL interface),
|
|
|
|
|
|
CVE-2020-8696 (Vector Register Leakage-Active),
|
|
|
|
|
|
CVE-2020-8698 (Fast Forward Store Predictor):
|
|
|
|
|
|
https://access.redhat.com/articles/5569051
|
2021-08-09 09:26:03 +00:00
|
|
|
|
* CVE-2020-24489 (VT-d-related Privilege Escalation),
|
|
|
|
|
|
CVE-2020-24511 (Improper Isolation of Shared Resources),
|
|
|
|
|
|
CVE-2020-24512 (Observable Timing Discrepancy),
|
|
|
|
|
|
CVE-2020-24513 (Information Disclosure on Some Intel Atom Processors):
|
|
|
|
|
|
https://access.redhat.com/articles/6101171
|
2022-04-26 13:50:19 +00:00
|
|
|
|
* CVE-2021-0127 (Intel Processor Breakpoint Control Flow),
|
|
|
|
|
|
CVE-2021-0145 (Fast store forward predictor - Cross Domain Training),
|
|
|
|
|
|
CVE-2021-0146 (VT-d-related Privilege Escalation),
|
|
|
|
|
|
CVE-2021-33120 (Out of bounds read for some Intel Atom processors):
|
|
|
|
|
|
https://access.redhat.com/articles/6716541
|
