import microcode_ctl-20200609-2.el8

This commit is contained in:
CentOS Sources 2020-07-28 04:28:48 -04:00 committed by Stepan Oksanichenko
parent ed8fb64027
commit fea0b7d605
27 changed files with 1396 additions and 193 deletions

4
.gitignore vendored
View File

@ -1,3 +1,7 @@
SOURCES/06-2d-07
SOURCES/06-4e-03
SOURCES/06-55-04
SOURCES/06-5e-03
SOURCES/microcode-20190918.tar.gz
SOURCES/microcode-20191115.tar.gz
SOURCES/microcode-20200609.tar.gz

View File

@ -1,3 +1,7 @@
bcf2173cd3dd499c37defbc2533703cfa6ec2430 SOURCES/06-2d-07
06432a25053c823b0e2a6b8e84e2e2023ee3d43e SOURCES/06-4e-03
2e405644a145de0f55517b6a9de118eec8ec1e5a SOURCES/06-55-04
86c60ee7d5d0d7115a4962c1c61ceecb0fd3a95a SOURCES/06-5e-03
bc20d6789e6614b9d9f88ee321ab82bed220f26f SOURCES/microcode-20190918.tar.gz
774636f4d440623b0ee6a2dad65260e81208074d SOURCES/microcode-20191115.tar.gz
c2a433c1f68c2dc5b752bd7dddf204ea89ad5761 SOURCES/microcode-20200609.tar.gz

View File

@ -1,3 +1,13 @@
model GenuineIntel 06-2d-07
path intel-ucode/06-2d-07
disable early late
## The "kernel_early" statements are carried over from the intel caveat config
## in order to avoid enabling this newer microcode on these problematic kernels;
## see the caveat description in /usr/share/doc/microcode_ctl/caveats/intel_readme
## (That also means that this caveat has to be enforced separately on these
## kernels.)
kernel_early 4.10.0
kernel_early 3.10.0-930
kernel_early 3.10.0-862.14.1
kernel_early 3.10.0-693.38.1
kernel_early 3.10.0-514.57.1
kernel_early 3.10.0-327.73.1

View File

@ -1,4 +1,4 @@
MDS-related microcode update for Intel Sandy Bridge-EP (family 6, model 45,
stepping 7; CPUID 0x206d7) CPUs is disabled as it may cause system instability.
stepping 7; CPUID 0x206d7) CPUs is disabled.
Please refer to /usr/share/doc/microcode_ctl/caveats/06-2d-07_readme
and /usr/share/doc/microcode_ctl/README.caveats for details.

View File

@ -1,17 +1,23 @@
Intel Sandy Bridge-E/EN/EP CPU models (SNB-EP, family 6, model 45, stepping 7)
have issues with MDS-related microcode update that may lead to a system hang
after a microcode update. In order to address this, microcode update
to the MDS-related revision 0x718 has been disabled, and the previously
had issues with MDS-related microcode update that may lead to a system hang
after a microcode update[1][2]. In order to address this, microcode update
to the MDS-related revision 0x718 had been disabled, and the previously
published microcode revision 0x714 is used by default for the OS-driven
microcode update.
microcode update. The revision 0x71a of the microcode is intended to fix
the aforementioned issue, hence it is enabled by default (but can be disabled
explicitly; see below).
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/15
[2] https://access.redhat.com/solutions/4593951
For the reference, SHA1 checksums of 06-2d-07 microcode files containing
microcode revisions in question are listed below:
* 06-2d-07, revision 0x714: bcf2173cd3dd499c37defbc2533703cfa6ec2430
* 06-2d-07, revision 0x718: 837cfebbfc09b911151dfd179082ad99cf87e85d
* 06-2d-07, revision 0x71a: 4512c8149e63e5ed15f45005d7fb5be0041f66f6
Please contact your system vendor for a BIOS/firmware update that contains
the latest microcode version. For the information regarding microcode versions
the latest microcode version. For the information regarding microcode versions
required for mitigating specific side-channel cache attacks, please refer
to the following knowledge base articles:
* CVE-2017-5715 ("Spectre"):
@ -24,30 +30,27 @@ to the following knowledge base articles:
("Microarchitectural Data Sampling"):
https://access.redhat.com/articles/4138151
The information regarding enforcing microcode load is provided below.
The information regarding disabling microcode update is provided below.
To enforce usage of the 0x718 microcode revision for a specific kernel version,
please create file "force-intel-06-2d-07" inside /lib/firmware/<kernel_version>
directory, run "/usr/libexec/microcode_ctl/update_ucode" to add it to firmware
directory where microcode will be available for late microcode update,
and run "dracut -f --kver <kernel_version>", so initramfs for this kernel
version is regenerated and the microcode can be loaded early, for example:
To disable usage of the newer microcode revision for a specific kernel
version, please create file "disallow-intel-06-2d-07" inside
/lib/firmware/<kernel_version> directory, run
"/usr/libexec/microcode_ctl/update_ucode" to add it to firmware directory
where microcode will be available for late microcode update, and run
"dracut -f --kver <kernel_version>", so initramfs for this kernel version
is regenerated and the microcode can be loaded early, for example:
touch /lib/firmware/3.10.0-862.9.1/force-intel-06-2d-07
touch /lib/firmware/3.10.0-862.9.1/disallow-intel-06-2d-07
/usr/libexec/microcode_ctl/update_ucode
dracut -f --kver 3.10.0-862.9.1
After that, it is possible to perform a late microcode update by executing
"/usr/libexec/microcode_ctl/reload_microcode" or by writing value "1" to
"/sys/devices/system/cpu/microcode/reload" directly.
To enforce addition of this microcode for all kernels, please create file
"/etc/microcode_ctl/ucode_with_caveats/force-intel-06-2d-07", run
"/usr/libexec/microcode_ctl/update_ucode" for enabling late microcode updates,
and "dracut -f --regenerate-all" for enabling early microcode updates:
To avoid addition of the newer microcode revision for all kernels, please create
file "/etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-2d-07", run
"/usr/libexec/microcode_ctl/update_ucode" for late microcode updates,
and "dracut -f --regenerate-all" for early microcode updates:
mkdir -p /etc/microcode_ctl/ucode_with_caveats
touch /etc/microcode_ctl/ucode_with_caveats/force-intel-06-2d-07
touch /etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-2d-07
/usr/libexec/microcode_ctl/update_ucode
dracut -f --regenerate-all

3
SOURCES/06-4e-03_config Normal file
View File

@ -0,0 +1,3 @@
model GenuineIntel 06-4e-03
path intel-ucode/06-4e-03
disable early late

View File

@ -0,0 +1,5 @@
Microcode revisions 0xda and higher for Intel Skylake-U/Y (family 6,
model 78, stepping 3; CPUID 0x406e3) are disabled as they may cause system
instability; the previously published revision 0xd6 is used instead.
Please refer to /usr/share/doc/microcode_ctl/caveats/06-4e-03_readme
and /usr/share/doc/microcode_ctl/README.caveats for details.

68
SOURCES/06-4e-03_readme Normal file
View File

@ -0,0 +1,68 @@
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
since 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 by default
for the OS-driven microcode update.
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
For the reference, SHA1 checksums of 06-55-04 microcode files containing
microcode revisions in question are listed below:
* 06-4e-03, revision 0xd6: 06432a25053c823b0e2a6b8e84e2e2023ee3d43e
* 06-4e-03, revision 0xdc: cd1733458d187486999337ff8b51eeaa0cfbca6c
Please contact your system vendor for a BIOS/firmware update that contains
the latest microcode version. For the information regarding microcode versions
required for mitigating specific side-channel cache attacks, please refer
to 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
The information regarding enforcing microcode update is provided below.
To enforce usage of the latest 06-4e-03 microcode revision for a specific kernel
version, please create a file "force-intel-06-4e-03" inside
/lib/firmware/<kernel_version> directory, run
"/usr/libexec/microcode_ctl/update_ucode" to add it to firmware directory
where microcode will be available for late microcode update, and run
"dracut -f --kver <kernel_version>", so initramfs for this kernel version
is regenerated and the microcode can be loaded early, for example:
touch /lib/firmware/3.10.0-862.9.1/force-intel-06-4e-03
/usr/libexec/microcode_ctl/update_ucode
dracut -f --kver 3.10.0-862.9.1
After that, it is possible to perform a late microcode update by executing
"/usr/libexec/microcode_ctl/reload_microcode" or by writing value "1" to
"/sys/devices/system/cpu/microcode/reload" directly.
To enforce addition of this microcode for all kernels, please create file
"/etc/microcode_ctl/ucode_with_caveats/force-intel-06-4e-03", run
"/usr/libexec/microcode_ctl/update_ucode" for enabling late microcode updates,
and "dracut -f --regenerate-all" for enabling early microcode updates:
mkdir -p /etc/microcode_ctl/ucode_with_caveats
touch /etc/microcode_ctl/ucode_with_caveats/force-intel-06-4e-03
/usr/libexec/microcode_ctl/update_ucode
dracut -f --regenerate-all
Please refer to /usr/share/doc/microcode_ctl/README.caveats for additional
information.

View File

@ -1,4 +1,4 @@
microcode update for Intel Broadwell-EP/EX (BDX-ML B/M/R0; family 6, model 79,
Microcode update for Intel Broadwell-EP/EX (BDX-ML B/M/R0; family 6, model 79,
stepping 1; CPUID 0x406f1) CPUs is disabled as it may cause system instability.
Please refer to /usr/share/doc/microcode_ctl/caveats/06-4f-01_readme
and /usr/share/doc/microcode_ctl/README.caveats for details.

View File

@ -1,3 +1,22 @@
model GenuineIntel 06-55-04
path intel-ucode/06-55-04
disable early late
## Bug https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/21
## affects only SKX-W/X (Workstation and HEDT segments); product segment
## can be determined by checking bits 5..3 of the CAPID0 field in PCU registers
## device (see https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-scalable-spec-update.pdf#page=13
## for Server/FPGA/Fabric segments description; for SKX-W/X no public
## documentation seems to be available). Specific device/function numbers
## are provided for speeding up the search only, VID:DID is the real selector.
## Commented out since revision 0x2006906 seems to fix the issue.
#pci_config_val mode=success-all device=0x1e function=3 vid=0x8086 did=0x2083 offset=0x84 size=4 mask=0x38 val=0x38,0x18,0x8
## The "kernel_early" statements are carried over from the intel caveat config
## in order to avoid enabling this newer microcode on these problematic kernels;
## see the caveat description in /usr/share/doc/microcode_ctl/caveats/intel_readme
## (That also means that this caveat has to be enforced separately on these
## kernels.)
kernel_early 4.10.0
kernel_early 3.10.0-930
kernel_early 3.10.0-862.14.1
kernel_early 3.10.0-693.38.1
kernel_early 3.10.0-514.57.1
kernel_early 3.10.0-327.73.1

View File

@ -1,6 +1,5 @@
Microcode revision 0x2000065 for Intel Skylake-SP/X/W (family 6, model 85,
stepping 4; CPUID 0x50654) CPUs that has been included into microcode-20191112
release is disabled as it may cause system instability and the previous revision
0x2000064 is used instead.
Microcode revisions 0x2000065 and higher for Intel Skylake-X/W (family 6,
model 85, stepping 4; CPUID 0x50654) were disabled as they could cause system
hangs on reboot, so the previous revision 0x2000064 was used instead.
Please refer to /usr/share/doc/microcode_ctl/caveats/06-55-04_readme
and /usr/share/doc/microcode_ctl/README.caveats for details.

View File

@ -1,14 +1,22 @@
Intel Skulake Scalable Platform CPU models (SKL-SP/W/X, family 6, model 85,
stepping 4) have reports of system hangs when revision 0x2000065 of microcode,
that is included since microcode-20191112 update, is applied. In order
to address this, microcode update to this revision has been disabled,
and the previously published microcode revision 0x2000064 is used by default
for the OS-driven microcode update.
Intel Skylake Scalable Platform CPU models that belong to Workstation and HEDT
(Basin Falls) segment (SKL-W/X, family 6, model 85, stepping 4) had reports
of system hangs on reboot when revision 0x2000065 of microcode, that was included
from microcode-20191112 update up to microcode-20200520 update, 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 0x2000064 is used by default for the OS-driven microcode update.
Since revision 0x2006906 (included with the microcode-20200609 release)
it is reported that the issue is no longer present, so the newer microcode
revision is enabled by default now (but can be disabled explicitly; see below).
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/21
For the reference, SHA1 checksums of 06-55-04 microcode files containing
microcode revisions in question are listed below:
* 06-55-04, revision 0x2000064: 2e405644a145de0f55517b6a9de118eec8ec1e5a
* 06-55-04, revision 0x2000065: f27f12b9d53f492c297afd856cdbc596786fad23
* 06-55-04, revision 0x2006906: 5f18f985f6d5ad369b5f6549b7f3ee55acaef967
Please contact your system vendor for a BIOS/firmware update that contains
the latest microcode version. For the information regarding microcode versions
@ -28,32 +36,32 @@ to the following knowledge base articles:
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
The information regarding enforcing microcode update is provided below.
The information regarding disabling microcode update is provided below.
To enforce usage of the 0x2000065 microcode revision for a specific kernel
version, please create a file "force-intel-06-55-04" inside
To disable usage of the newer microcode revision for a specific kernel
version, please create a file "disallow-intel-06-55-04" inside
/lib/firmware/<kernel_version> directory, run
"/usr/libexec/microcode_ctl/update_ucode" to add it to firmware directory
where microcode will be available for late microcode update, and run
"dracut -f --kver <kernel_version>", so initramfs for this kernel version
is regenerated and the microcode can be loaded early, for example:
"/usr/libexec/microcode_ctl/update_ucode" to update firmware directory
used for late microcode updates, and run "dracut -f --kver <kernel_version>"
so initramfs for this kernel version is regenerated, for example:
touch /lib/firmware/3.10.0-862.9.1/force-intel-06-55-04
touch /lib/firmware/3.10.0-862.9.1/disallow-intel-06-55-04
/usr/libexec/microcode_ctl/update_ucode
dracut -f --kver 3.10.0-862.9.1
After that, it is possible to perform a late microcode update by executing
"/usr/libexec/microcode_ctl/reload_microcode" or by writing value "1" to
"/sys/devices/system/cpu/microcode/reload" directly.
To enforce addition of this microcode for all kernels, please create file
"/etc/microcode_ctl/ucode_with_caveats/force-intel-06-55-04", run
"/usr/libexec/microcode_ctl/update_ucode" for enabling late microcode updates,
and "dracut -f --regenerate-all" for enabling early microcode updates:
To disable usage of the newer microcode revision for all kernels, please create
file "/etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-55-04", run
"/usr/libexec/microcode_ctl/update_ucode" to update firmware directories
used for late microcode updates, and run "dracut -f --regenerate-all"
so initramfs images get regenerated, for example:
mkdir -p /etc/microcode_ctl/ucode_with_caveats
touch /etc/microcode_ctl/ucode_with_caveats/force-intel-06-55-04
touch /etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-55-04
/usr/libexec/microcode_ctl/update_ucode
dracut -f --regenerate-all

3
SOURCES/06-5e-03_config Normal file
View File

@ -0,0 +1,3 @@
model GenuineIntel 06-5e-03
path intel-ucode/06-5e-03
disable early late

View File

@ -0,0 +1,5 @@
Microcode revisions 0xda and higher for Intel Skylake-H/S/Xeon E3 v5 (family 6,
model 94, stepping 3; CPUID 0x506e3) are disabled as they may cause system
instability; the previously published revision 0xd6 is used instead.
Please refer to /usr/share/doc/microcode_ctl/caveats/06-5e-03_readme
and /usr/share/doc/microcode_ctl/README.caveats for details.

68
SOURCES/06-5e-03_readme Normal file
View File

@ -0,0 +1,68 @@
Some Intel Skylake CPU models (SKL-H/S/Xeon E3 v5, family 6, model 94,
stepping 3) have reports of possible 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 by default for the OS-driven microcode update.
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-644885826
For the reference, SHA1 checksums of 06-55-04 microcode files containing
microcode revisions in question are listed below:
* 06-5e-03, revision 0xd6: 86c60ee7d5d0d7115a4962c1c61ceecb0fd3a95a
* 06-5e-03, revision 0xdc: 5e1020a10678cfc60980131c3d3a2cfd462b4dd7
Please contact your system vendor for a BIOS/firmware update that contains
the latest microcode version. For the information regarding microcode versions
required for mitigating specific side-channel cache attacks, please refer
to 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
The information regarding enforcing microcode update is provided below.
To enforce usage of the latest 06-5e-03 microcode revision for a specific kernel
version, please create a file "force-intel-06-5e-03" inside
/lib/firmware/<kernel_version> directory, run
"/usr/libexec/microcode_ctl/update_ucode" to add it to firmware directory
where microcode will be available for late microcode update, and run
"dracut -f --kver <kernel_version>", so initramfs for this kernel version
is regenerated and the microcode can be loaded early, for example:
touch /lib/firmware/3.10.0-862.9.1/force-intel-06-5e-03
/usr/libexec/microcode_ctl/update_ucode
dracut -f --kver 3.10.0-862.9.1
After that, it is possible to perform a late microcode update by executing
"/usr/libexec/microcode_ctl/reload_microcode" or by writing value "1" to
"/sys/devices/system/cpu/microcode/reload" directly.
To enforce addition of this microcode for all kernels, please create file
"/etc/microcode_ctl/ucode_with_caveats/force-intel-06-5e-03", run
"/usr/libexec/microcode_ctl/update_ucode" for enabling late microcode updates,
and "dracut -f --regenerate-all" for enabling early microcode updates:
mkdir -p /etc/microcode_ctl/ucode_with_caveats
touch /etc/microcode_ctl/ucode_with_caveats/force-intel-06-5e-03
/usr/libexec/microcode_ctl/update_ucode
dracut -f --regenerate-all
Please refer to /usr/share/doc/microcode_ctl/README.caveats for additional
information.

View File

@ -0,0 +1,4 @@
path intel-ucode/*
vendor GenuineIntel
dmi mode=fail-equal key=bios_vendor val="Dell Inc."
disable early late

View File

View File

@ -0,0 +1,123 @@
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
This caveat contains revision 0xca of 06-[89]e-0x microcode publicly released
by Intel; for the latest revision of the microcode files, please refer to caveat
06-8e-9e-0x-dell.
For the reference, microarchitectures of the affected CPU models:
* Amber Lake-Y
* Kaby Lake-G/H/S/U/Y/Xeon E3
* Coffee Lake-H/S/U/Xeon E
* Comet Lake-U 4+2
* Whiskey Lake-U
Family names of the affected CPU models:
* 7th Generation Intel® Core™ Processor Family
* 8th Generation Intel® Core™ Processor Family
* 9th Generation Intel® Core™ Processor Family
* 10th Generation Intel® Core™ Processor Family (selected models)
* Intel® Celeron® Processor G Series
* Intel® Celeron® Processor 5000 Series
* Intel® Core™ X-series Processors (i7-7740X, i5-7640X only)
* Intel® Pentium® Gold Processor Series
* Intel® Pentium® Processor Series (selected models)
* Intel® Xeon® Processor E Family
* Intel® Xeon® Processor E3 v6 Family
SHA1 checksums of the microcode files containing microcode revisions
in question:
* 06-8e-09, revision 0xb4: e253c95c29c3eef6576db851dfa069d82a91256f
* 06-8e-0a, revision 0xb4: 45bcba494be07df9eeccff9627578095a97fba4d
* 06-8e-0b, revision 0xb8: 3e54bf91d642ad81ff07fe274d0cfb5d10d09c43
* 06-8e-0c, revision 0xb8: bf635c87177d6dc4e067ec11e1caeb19d3c325f0
* 06-9e-09, revision 0xb4: 42f68eec4ddb79dd6be0c95c4ce60e514e4504b1
* 06-9e-0a, revision 0xb4: 37c7cb394dd36610b57943578343723da67d50f0
* 06-9e-0b, revision 0xb4: b5399109d0a5ce8f5fb623ff942da0322b438b95
* 06-9e-0c, revision 0xae: 131bce89e4d210de8322ffbc6bd787f1af66a7df
* 06-9e-0d, revision 0xb8: 22511b007d1df55558d115abb13a1c23ea398317
* 06-8e-09, revision 0xca: 9afa1bae40995207afef13247f114be042d88083
* 06-8e-0a, revision 0xca: 1d90291cc25e17dc6c36c764cf8c06b41fed4c16
* 06-8e-0b, revision 0xca: 3fb1246a6594eff5e2c2076c63c600d734f10777
* 06-8e-0c, revision 0xca: e871540671f59b4fa5d0d454798f09a4d412aace
* 06-9e-09, revision 0xca: b5eed11108ab7ac1e675fe75d0e7454a400ddd35
* 06-9e-0a, revision 0xca: e472304aaa2f3815a32822cb111ab3f43bf3dfe4
* 06-9e-0b, revision 0xca: 78f47c5162da680878ed057dc7c853f9737c524b
* 06-9e-0c, revision 0xca: f23848a009928796a153cb9e8f44522136969408
* 06-9e-0d, revision 0xca: c7a3d469469ee828ba9faf91b67af881fceec3b7
* 06-8e-09, revision 0xd6: 2272c621768437d20e602207752201e0966e5a8c
* 06-8e-0a, revision 0xd6: 0b145afb88e028e612f04c2a86385e7d7c3fefc4
* 06-8e-0b, revision 0xd6: c3831b05da83be54f3acc451a1bce90f75e2e9e5
* 06-8e-0c, revision 0xd6: 4b8938a93e23f4b5a2d9de40b87f6afcfdc27c05
* 06-9e-09, revision 0xd6: 4bacba8c598508e7dd4e87e179586abe7a1a987f
* 06-9e-0a, revision 0xd6: 4c236afeef9f80ff3a286698fe7cef72926722f0
* 06-9e-0b, revision 0xd6: 2f9ab9b2ba29559ce177632281d7290a24fed2ef
* 06-9e-0c, revision 0xd6: 4b9059e519bcab6085b6c103f5d99e509fe0b2bb
* 06-9e-0d, revision 0xd6: 3a3b7edfd8126bb34b761b46a32102a622047899
Please contact your system vendor for a BIOS/firmware update that contains
the latest microcode version. For the information regarding microcode versions
required for mitigating specific side-channel cache attacks, please refer
to 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
The information regarding disabling microcode update is provided below.
To disable usage of the newer microcode revision for a specific kernel
version, please create a file "disallow-intel-06-8e-9e-0x-0xca" inside
/lib/firmware/<kernel_version> directory, run
"/usr/libexec/microcode_ctl/update_ucode" to update firmware directory
used for late microcode updates, and run "dracut -f --kver <kernel_version>"
so initramfs for this kernel version is regenerated, for example:
touch /lib/firmware/3.10.0-862.9.1/disallow-intel-06-8e-9e-0x-0xca
/usr/libexec/microcode_ctl/update_ucode
dracut -f --kver 3.10.0-862.9.1
To disable usage of the newer microcode revision for all kernels, please create
file "/etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-8e-9e-0x-0xca",
run "/usr/libexec/microcode_ctl/update_ucode" to update firmware directories
used for late microcode updates, and run "dracut -f --regenerate-all"
so initramfs images get regenerated, for example:
mkdir -p /etc/microcode_ctl/ucode_with_caveats
touch /etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-8e-9e-0xca
/usr/libexec/microcode_ctl/update_ucode
dracut -f --regenerate-all
Please refer to /usr/share/doc/microcode_ctl/README.caveats for additional
information.

View File

@ -0,0 +1,17 @@
path intel-ucode/*
vendor GenuineIntel
## It is deemed that blacklisting all 06-[89]e-0x models on all hardware
## in cases where no model filter is used is too broad, hence
## no-model-mode=success.
dmi mode=fail-equal no-model-mode=success key=bios_vendor val="Dell Inc."
## The "kernel_early" statements are carried over from the intel caveat config
## in order to avoid enabling this newer microcode on these problematic kernels;
## see the caveat description in /usr/share/doc/microcode_ctl/caveats/intel_readme
## (That also means that this caveat has to be enforced separately on these
## kernels.)
kernel_early 4.10.0
kernel_early 3.10.0-930
kernel_early 3.10.0-862.14.1
kernel_early 3.10.0-693.38.1
kernel_early 3.10.0-514.57.1
kernel_early 3.10.0-327.73.1

View File

@ -0,0 +1,7 @@
Some Dell systems that use some models of Intel CPUs are susceptible to hangs
and system instability during or after microcode update to newer revisions.
In order to address this, microcode update to these newer revision
has been disabled by default on these systems, and the previously published
microcode revisions are used by default for the OS-driven microcode update.
Please refer to /usr/share/doc/microcode_ctl/caveats/06-8e-9e-0x-dell_readme
and /usr/share/doc/microcode_ctl/README.caveats for details.

View File

@ -0,0 +1,123 @@
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
This caveat contains latest microcode revisions publicly released by Intel;
for the revision 0xca of the microcode files, please refer to caveat
06-8e-9e-0x-0xca.
For the reference, microarchitectures of the affected CPU models:
* Amber Lake-Y
* Kaby Lake-G/H/S/U/X/Y/Xeon E3
* Coffee Lake-H/S/U/Xeon E
* Comet Lake-U 4+2
* Whiskey Lake-U
Family names of the affected CPU models:
* 7th Generation Intel® Core™ Processor Family
* 8th Generation Intel® Core™ Processor Family
* 9th Generation Intel® Core™ Processor Family
* 10th Generation Intel® Core™ Processor Family (selected models)
* Intel® Celeron® Processor G Series
* Intel® Celeron® Processor 5000 Series
* Intel® Core™ X-series Processors (i7-7740X, i5-7640X only)
* Intel® Pentium® Gold Processor Series
* Intel® Pentium® Processor Series (selected models)
* Intel® Xeon® Processor E Family
* Intel® Xeon® Processor E3 v6 Family
SHA1 checksums of the microcode files containing microcode revisions
in question:
* 06-8e-09, revision 0xb4: e253c95c29c3eef6576db851dfa069d82a91256f
* 06-8e-0a, revision 0xb4: 45bcba494be07df9eeccff9627578095a97fba4d
* 06-8e-0b, revision 0xb8: 3e54bf91d642ad81ff07fe274d0cfb5d10d09c43
* 06-8e-0c, revision 0xb8: bf635c87177d6dc4e067ec11e1caeb19d3c325f0
* 06-9e-09, revision 0xb4: 42f68eec4ddb79dd6be0c95c4ce60e514e4504b1
* 06-9e-0a, revision 0xb4: 37c7cb394dd36610b57943578343723da67d50f0
* 06-9e-0b, revision 0xb4: b5399109d0a5ce8f5fb623ff942da0322b438b95
* 06-9e-0c, revision 0xae: 131bce89e4d210de8322ffbc6bd787f1af66a7df
* 06-9e-0d, revision 0xb8: 22511b007d1df55558d115abb13a1c23ea398317
* 06-8e-09, revision 0xca: 9afa1bae40995207afef13247f114be042d88083
* 06-8e-0a, revision 0xca: 1d90291cc25e17dc6c36c764cf8c06b41fed4c16
* 06-8e-0b, revision 0xca: 3fb1246a6594eff5e2c2076c63c600d734f10777
* 06-8e-0c, revision 0xca: e871540671f59b4fa5d0d454798f09a4d412aace
* 06-9e-09, revision 0xca: b5eed11108ab7ac1e675fe75d0e7454a400ddd35
* 06-9e-0a, revision 0xca: e472304aaa2f3815a32822cb111ab3f43bf3dfe4
* 06-9e-0b, revision 0xca: 78f47c5162da680878ed057dc7c853f9737c524b
* 06-9e-0c, revision 0xca: f23848a009928796a153cb9e8f44522136969408
* 06-9e-0d, revision 0xca: c7a3d469469ee828ba9faf91b67af881fceec3b7
* 06-8e-09, revision 0xd6: 2272c621768437d20e602207752201e0966e5a8c
* 06-8e-0a, revision 0xd6: 0b145afb88e028e612f04c2a86385e7d7c3fefc4
* 06-8e-0b, revision 0xd6: c3831b05da83be54f3acc451a1bce90f75e2e9e5
* 06-8e-0c, revision 0xd6: 4b8938a93e23f4b5a2d9de40b87f6afcfdc27c05
* 06-9e-09, revision 0xd6: 4bacba8c598508e7dd4e87e179586abe7a1a987f
* 06-9e-0a, revision 0xd6: 4c236afeef9f80ff3a286698fe7cef72926722f0
* 06-9e-0b, revision 0xd6: 2f9ab9b2ba29559ce177632281d7290a24fed2ef
* 06-9e-0c, revision 0xd6: 4b9059e519bcab6085b6c103f5d99e509fe0b2bb
* 06-9e-0d, revision 0xd6: 3a3b7edfd8126bb34b761b46a32102a622047899
Please contact your system vendor for a BIOS/firmware update that contains
the latest microcode version. For the information regarding microcode versions
required for mitigating specific side-channel cache attacks, please refer
to 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
The information regarding disabling microcode update is provided below.
To disable usage of the newer microcode revision for a specific kernel
version, please create a file "disallow-intel-06-8e-9e-0x-dell" inside
/lib/firmware/<kernel_version> directory, run
"/usr/libexec/microcode_ctl/update_ucode" to update firmware directory
used for late microcode updates, and run "dracut -f --kver <kernel_version>"
so initramfs for this kernel version is regenerated, for example:
touch /lib/firmware/3.10.0-862.9.1/disallow-intel-06-8e-9e-0x-dell
/usr/libexec/microcode_ctl/update_ucode
dracut -f --kver 3.10.0-862.9.1
To disable usage of the newer microcode revision for all kernels, please create
file "/etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-8e-9e-0x-dell",
run "/usr/libexec/microcode_ctl/update_ucode" to update firmware directories
used for late microcode updates, and run "dracut -f --regenerate-all"
so initramfs images get regenerated, for example:
mkdir -p /etc/microcode_ctl/ucode_with_caveats
touch /etc/microcode_ctl/ucode_with_caveats/disallow-intel-06-8e-9e-dell
/usr/libexec/microcode_ctl/update_ucode
dracut -f --regenerate-all
Please refer to /usr/share/doc/microcode_ctl/README.caveats for additional
information.

View File

@ -160,6 +160,83 @@ separated by white space. Currently, the following options are supported:
one model name per line. The model name of the running CPU (as reported
in /proc/cpuinfo) is compared against the names in the provided list, and,
if there is a match, caveat check fails.
* "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
(present under /sys/devices/virtual/dmi/id/). The check fails if file
is not readable. If "-m" option is specified, then the actual check
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.
* "val" - a string to match DMI data against. Can be enclosed in single
or double quotes. Default is empty string.
* "mode" - check mode, the way matches are interpreted:
* "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
of "val" parameter, otherwise 1.
* "success-equal" - returns 1 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
of "val" parameter, otherwise 0.
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.
check_caveats script
@ -438,38 +515,119 @@ Minimum versions of the kernel package that contain the fix:
Intel Sandy Bridge-E/EN/EP caveat
---------------------------------
MDS-related microcode revision 0x718 for Intel Sandy Bridge-E/EN/EP
(SNB-EP, family 6, model 45, stepping 7) may lead to system instability.
In order to address this, this microcode update is not used and the previous
microcode revision is provided instead by default; the microcode file, 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. (See
the sections "check_caveats script" and "reload_microcode script" for details.)
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.
Mitigation: previously published microcode revision 0x714 is used by default.
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 for Intel Skylake Scalable Platform (SKL-SP/W/X,
family 6, model 85, stepping 4) may lead to system instability.
In order to address this, this microcode update is not used and the previous
microcode revision is provided instead by default; the microcode file, 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.
(See the sections "check_caveats script" and "reload_microcode script"
for details.)
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.
Mitigation: previously published microcode revision 0x2000064 is used
by default.
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.
Intel Skylake-U/Y/H/S/Xeon E3 v5 caveats
----------------------------------------
Some Intel Skylake CPU models (SKL-U/Y, family 6, model 78, stepping 3;
and SKL-H/S/Xeon E3 v5, family 6, model 94, 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][2]. 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.)
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
[2] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-644885826
Caveat names: intel-06-4e-03, intel-06-5e-03
Affected microcode: intel-ucode/06-4e-03, intel-ucode/06-5e-03.
Mitigation: previously published microcode revision 0xd6 is used by default.
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.
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.
@ -496,3 +654,7 @@ Intel CPU vulnerabilities is available in the following knowledge base articles:
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

View File

@ -132,6 +132,226 @@ check_kver()
return 1
}
# It is needed for SKX[1] for which different product segments
# are differentiated by a value in the CAPID0 field of PCU registers
# device[2].
# [1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/21
# [2] https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-scalable-spec-update.pdf#page=13
#
# $1 - params in config file, space-separated, in key=value form:
# domain=* - PCI domain, '*' or number
# bus=* - PCI bus, '*' or number
# device=* - PCI device, '*' or number
# function=* - PCI function, '*' or number
# vid= - PCI vendor ID, empty or number
# did= - PCI device ID, empty or number
# offset=0 - offset in configuration space
# size=4 - field size
# mask=0 - mask applied to the data read
# val=0 - comma-separated list of possible values
# mode=success-any [ success-ail, fail-any, fail-all ] - matching mode:
# success-any: Returns 0 if there was at least one match, otherwise 1.
# success-all: Returns 0 if there was at least one device checked and all
# the checked devices have matches, otherwise 1.
# fail-any: Returns 1 if there was at least one match, otherwise 0.
# fail-all: Returns 1 if there was at least one device checked and all
# the checked devices have matches, otherwise 0.
# $2 - whether model filter is engaged (if it is not '1', just return the result
# based on "mode" value that assumes that there were 0 checks/0 matches).
check_pci_config_val()
{
local domain='*' bus='*' device='*' func='*' vid= did=
local offset=0 size=4 mask=0 val=0 mode=success-any
local checked=0 matched=0 path=''
local dev_path dev_vid dev_did dev_val
local opts="${1:-}"
local match_model="${2:0}"
set -- $1
while [ "$#" -gt 0 ]; do
[ "x${1#domain=}" = "x${1}" ] || domain="${1#domain=}"
[ "x${1#bus=}" = "x${1}" ] || bus="${1#bus=}"
[ "x${1#device=}" = "x${1}" ] || device="${1#device=}"
[ "x${1#function=}" = "x${1}" ] || func="${1#function=}"
[ "x${1#vid=}" = "x${1}" ] || vid="${1#vid=}"
[ "x${1#did=}" = "x${1}" ] || did="${1#did=}"
[ "x${1#offset=}" = "x${1}" ] || offset="${1#offset=}"
[ "x${1#size=}" = "x${1}" ] || size="${1#size=}"
[ "x${1#mask=}" = "x${1}" ] || mask="${1#mask=}"
[ "x${1#val=}" = "x${1}" ] || val="${1#val=}"
[ "x${1#mode=}" = "x${1}" ] || mode="${1#mode=}"
shift
done
path="$domain"
if [ "x$bus" = 'x*' ]; then
path="$path:$bus";
else
path=$(printf '%s:%02x' "$path" "$bus")
fi
if [ "x$device" = 'x*' ]; then
path="$path:$device";
else
path=$(printf '%s:%02x' "$path" "$device")
fi
if [ "x$func" = 'x*' ]; then
path="$path.$func";
else
path=$(printf '%s.%01x' "$path" "$func")
fi
# Normalise VID, DID
[ -n "$vid" ] || vid="$(printf '0x%04x' "$vid")"
[ -n "$did" ] || did="$(printf '0x%04x' "$did")"
( [ 1 != "$match_model" ] \
|| /usr/bin/find /sys/bus/pci/devices/ -maxdepth 1 -name "$path" \
|| : ) | (
while read -r dev_path; do
# Filter VID, DID
if [ -n "$vid" ]; then
dev_vid=$(/bin/cat "$dev_path/vendor")
[ "x$vid" = "x$dev_vid" ] || continue
fi
if [ -n "$did" ]; then
dev_did=$(/bin/cat "$dev_path/device")
[ "x$did" = "x$dev_did" ] || continue
fi
checked="$((checked + 1))"
dev_val="$(/usr/bin/od -j "$offset" -N "$size" -A n \
-t "u$size" "$dev_path/config")"
val_rest="${val}"
while :; do
cur_val="${val_rest%%,*}"
if [ "$((dev_val & mask))" = "$((cur_val & mask))" ]
then
matched="$((matched + 1))"
break
fi
[ "x${val_rest}" != "x${val_rest#*,}" ] || break
val_rest="${val_rest#*,}"
done
case "$mode" in
success-any) [ "$matched" -eq 0 ] || { echo 0; exit; } ;;
success-all) [ "$matched" -eq "$checked" ] || { echo 1; exit; } ;;
fail-any) [ "$matched" -eq 0 ] || { echo 1; exit; } ;;
fail-all) [ "$matched" -eq "$checked" ] || { echo 0; exit; } ;;
*) echo 2; exit;;
esac
done
debug "PCI config value check ($opts): checked $checked," \
"matched $matched (model check is set to $match_model)"
case "$mode" in
success-any) if [ "$matched" -eq 0 ]; then echo 1; else echo 0; fi ;;
success-all) if [ "$matched" -gt 0 -a "$matched" -eq "$checked" ]; then echo 0; else echo 1; fi ;;
fail-any) if [ "$matched" -eq 0 ]; then echo 0; else echo 1; fi ;;
fail-all) if [ "$matched" -gt 0 -a "$matched" -eq "$checked" ]; then echo 1; else echo 0; fi ;;
*) echo 2; exit;;
esac
)
}
# It is needed for filtering by BIOS vendor name that is available in DMI data
#
# $1 - params in config file, space-separated, in key=value form:
# key= - DMI value to check. 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.
# val= - a string to match DMI data against. Can be enclosed in single
# or double quotes.
# mode=success-equal [ success-equal, fail-equal ] - matching mode:
# success-equal: Returns 0 if the value present in the corresponding file
# under /sys/devices/virtual/dmi/id/<key> is equal
# to the value supplied as a value of "val" parameter,
# otherwise 1.
# fail-equal: Returns 1 if the value present in the corresponding file
# under /sys/devices/virtual/dmi/id/<key> is equal
# to the value supplied as a value of "val" parameter,
# otherwise 0.
# no-model-mode=success [ success, fail ] - return value if model filter
# is not enabled:
# success: Return 0.
# fail: Return 1.
# $2 - whether model filter is engaged (if it is not '1', just return the result
# based on "mode" value that assumes that the check has failed).
check_dmi_val()
{
local key= val= mode='success-equal' nm_mode='success'
local opts="${1:-}" opt= opt_=
local match_model="${2:0}"
local valid_keys=" 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 "
local success=1
while [ -n "$opts" ]; do
opt="${opts%%[ ]*}"
[ -n "${opt}" ] || { opts="${opts#[ ]}"; continue; }
[ "x${opt#key=}" = "x${opt}" ] || key="${opt#key=}"
[ "x${opt#mode=}" = "x${opt}" ] || mode="${opt#mode=}"
[ "x${opt#no-model-mode=}" = "x${opt}" ] || \
nm_mode="${opt#no-model-mode=}"
# Handle possible quoting
[ "x${opt#val=}" = "x${opt}" ] || {
case "${opt#val=}" in
[']*) opt_="${opts#val=\'}"; val="${opt_%%\'*}"; opt="val=\'${val}\'" ;;
["]*) opt_="${opts#val=\"}"; val="${opt_%%\"*}"; opt="val=\"${val}\"" ;;
*) val="${opt#val=}" ;;
esac
}
opts="${opts#"${opt}"}"
continue
done
# Check key for validity
[ "x${valid_keys#* ${key} *}" != "x${valid_keys}" ] || {
debug "Invalid \"key\" parameter value: \"${key}\""
echo 2
exit
}
[ 1 = "$match_model" ] || {
case "$nm_mode" in
success) echo 0 ;;
fail) echo 1 ;;
*)
debug "Invalid no-model-mode value: \"${nm_mode}\""
echo 2
;;
esac
exit
}
[ -r "/sys/devices/virtual/dmi/id/${key}" ] || {
debug "Can't access /sys/devices/virtual/dmi/id/${key}"
echo 3
exit
}
file_val="$(cat "/sys/devices/virtual/dmi/id/${key}")"
[ "x${val}" = "x${file_val}" ] || success=0
case "$mode" in
success-equal) echo "$((1 - $success))" ;;
fail-equal) echo "${success}" ;;
*) debug "Invalid mode value: \"${nm_mode}\""; echo 2 ;;
esac
}
# Provides model in format "VENDOR_ID FAMILY-MODEL-STEPPING"
#
# We check only the first processor as we don't expect non-symmetrical setups
@ -182,7 +402,7 @@ fail()
fail_paths="$fail_paths $cfg_path"
[ 0 -eq "$print_disclaimers" ] || [ ! -e "${dir}/disclaimer" ] \
|| cat "${dir}/disclaimer"
|| /bin/cat "${dir}/disclaimer"
}
#check_kver "$@"
@ -225,7 +445,7 @@ while getopts "dek:c:mv" opt; do
esac
done
: ${configs:=$(find "${MC_CAVEATS_DATA_DIR}" -maxdepth 1 -mindepth 1 -type d -printf "%f\n")}
: "${configs:=$(find "${MC_CAVEATS_DATA_DIR}" -maxdepth 1 -mindepth 1 -type d -printf "%f\n")}"
cpu_model=$(get_model_string)
cpu_model_name=$(get_model_name)
@ -273,6 +493,8 @@ for cfg in $(echo "${configs}"); do
cfg_blacklist=
cfg_mc_min_ver_late=
cfg_disable=
cfg_pci=
cfg_dmi=
while read -r key value; do
case "$key" in
@ -299,8 +521,26 @@ for cfg in $(echo "${configs}"); do
;;
blacklist)
cfg_blacklist=1
# "blacklist" is special: it stops entity parsing,
# and the rest of file is a list of blacklisted model
# names.
break
;;
pci_config_val)
cfg_pci="$cfg_pci
$value"
;;
dmi)
cfg_dmi="$cfg_dmi
$value"
;;
'#'*|'')
continue
;;
*)
debug "Unknown key '$key' (value '$value') in config" \
"'$cfg'"
;;
esac
done < "${dir}/config"
@ -388,12 +628,14 @@ for cfg in $(echo "${configs}"); do
cfg_mc_present=0
for p in $(printf "%s" "$cfg_path"); do
find "$MC_CAVEATS_DATA_DIR/$cfg" \
-path "$MC_CAVEATS_DATA_DIR/$cfg/$p" -print0 \
| grep -zFxq "$cpu_mc_path" \
{ /usr/bin/find "$MC_CAVEATS_DATA_DIR/$cfg" \
-path "$MC_CAVEATS_DATA_DIR/$cfg/$p" -print0;
/bin/true; } \
| /bin/grep -zFxq "$cpu_mc_path" \
|| continue
cfg_mc_present=1
break
done
[ 1 = "$cfg_mc_present" ] || {
@ -478,6 +720,51 @@ for cfg in $(echo "${configs}"); do
}
fi
# Check PCI devices if model filter is enabled
# Note that the model filter check is done inside check_pci_config_val
# based on the 'mode=' parameter.
if [ -n "$cfg_pci" ]; then
pci_line="$(printf "%s\n" "$cfg_pci" | while read -r pci_line; do
[ -n "$pci_line" ] || continue
pci_res=$(check_pci_config_val "$pci_line" \
"$match_model")
[ 0 != "$pci_res" ] || continue
echo "$pci_res $pci_line"
break
done
echo "0 ")"
[ -z "${pci_line#* }" ] || {
debug "PCI configuration word check '${pci_line#* }'" \
"failed (with return code ${pci_line%% *})"
fail
continue
}
fi
# Check DMI data if model filter is enabled
# Note that the model filter check is done inside check_pci_config_val
# based on the 'mode=' parameter.
if [ -n "$cfg_dmi" ]; then
dmi_line="$(printf "%s\n" "$cfg_dmi" | while read -r dmi_line
do
[ -n "$dmi_line" ] || continue
dmi_res=$(check_dmi_val "$dmi_line" \
"$match_model")
[ 0 != "$dmi_res" ] || continue
echo "$dmi_res $dmi_line"
break
done
echo "0 ")"
[ -z "${dmi_line#* }" ] || {
debug "DMI data check '${dmi_line#* }'" \
"failed (with return code ${dmi_line%% *})"
fail
continue
}
fi
ok_cfgs="$ok_cfgs $cfg"
ok_paths="$ok_paths $cfg_path"
done

View File

@ -48,29 +48,6 @@ install() {
dinfo " microcode_ctl: processing data directory " \
"\"$DATA_DIR/$i\"..."
if ! cc_out=$($check_caveats -e -k "$kernel" -c "$i" $verbose_opt)
then
dinfo " microcode_ctl: kernel version \"$kernel\"" \
"failed early load check for \"$i\", skipping"
continue
fi
path=$(printf "%s" "$cc_out" | sed -n 's/^paths //p')
[ -n "$path" ] || {
ignored=$(printf "%s" "$cc_out" | \
sed -n 's/^skip_cfgs //p')
if [ -n "$ignored" ]; then
dinfo " microcode_ctl: configuration" \
"\"$i\" is ignored"
else
dinfo " microcode_ctl: no microcode paths" \
"are associated with \"$i\", skipping"
fi
continue
}
if [ "x" != "x$hostonly" ]; then
do_skip_host_only=0
@ -92,57 +69,33 @@ install() {
do_skip_host_only=1
fi
if [ 0 -eq "$do_skip_host_only" ]; then
local hostonly_passed=0
local ucode
local uvendor
local ucode_dir=""
match_model_opt=""
[ 1 = "$do_skip_host_only" ] || match_model_opt="-m"
ucode=$(get_ucode_file)
uvendor=$(get_cpu_vendor)
case "$uvendor" in
Intel)
ucode_dir="intel-ucode"
;;
AMD)
ucode_dir="amd-ucode"
;;
*)
dinfo " microcode_ctl: unknown CPU" \
"vendor: \"$uvendor\", bailing out of" \
"Host-Only check"
continue
;;
esac
# $path is a list of globs, so it needs special care
for p in $(printf "%s" "$path"); do
# "true" is due to sporadic SIGPIPE from find
# when "grep -q" exits early.
{ find "$DATA_DIR/$i" -path "$DATA_DIR/$i/$p" \
-print0; true; } \
| grep -zFxq \
"$DATA_DIR/$i/$ucode_dir/$ucode" \
|| continue
dinfo " microcode_ctl: $i: Host-Only" \
"mode is enabled and" \
"\"$ucode_dir/$ucode\" matches \"$p\""
hostonly_passed=1
break
done
[ 1 -eq "$hostonly_passed" ] || {
dinfo " microcode_ctl: $i: Host-Only mode" \
"is enabled and ucode name does not" \
"match the expected one, skipping" \
"caveat (\"$ucode\" not in \"$path\")"
continue
}
if ! cc_out=$($check_caveats -e -k "$kernel" -c "$i" \
$verbose_opt $match_model_opt)
then
dinfo " microcode_ctl: kernel version \"$kernel\"" \
"failed early load check for \"$i\", skipping"
continue
fi
path=$(printf "%s" "$cc_out" | sed -n 's/^paths //p')
[ -n "$path" ] || {
ignored=$(printf "%s" "$cc_out" | \
sed -n 's/^skip_cfgs //p')
if [ -n "$ignored" ]; then
dinfo " microcode_ctl: configuration" \
"\"$i\" is ignored"
else
dinfo " microcode_ctl: no microcode paths" \
"are associated with \"$i\", skipping"
fi
continue
}
dinfo " microcode_ctl: $i: caveats check for kernel" \
"version \"$kernel\" passed, adding" \
"\"$DATA_DIR/$i\" to fw_dir variable"

View File

@ -21,31 +21,75 @@ for f in $(grep -E '/intel-ucode.*/[0-9a-f][0-9a-f]-[0-9a-f][0-9a-f]-[0-9a-f][0-
ucode_fname="$ucode_caveat/$ucode"
file_sz="$(stat -c "%s" "$f")"
skip=0
ext_hdr=0
ext_sig_cnt=0
ext_sig_pos=0
next_skip=0
# Microcode header format description:
# https://gitlab.com/iucode-tool/iucode-tool/blob/master/intel_microcode.c
while :; do
[ "$skip" -lt "$file_sz" ] || break
# Microcode header format description:
# https://gitlab.com/iucode-tool/iucode-tool/blob/master/intel_microcode.c
IFS=' ' read hdrver rev \
date_y date_d date_m \
cpuid cksum ldrver \
pf_mask datasz totalsz <<- EOF
$(dd if="$f" bs=1 skip="$skip" count=36 status=none \
| hexdump -e '"" 1/4 "%u " 1/4 "%#x " \
1/2 "%04x " 1/1 "%02x " 1/1 "%02x " \
1/4 "%08x " 1/4 "%x " 1/4 "%#x " \
1/4 "%u " 1/4 "%u " 1/4 "%u" "\n"')
EOF
# Do we parse ext_sig table or another microcode header?
if [ 0 != "$next_skip" ]; then
# Check whether we should abort ext_sig table parsing
[ \( "${skip}" -lt "${next_skip}" \) -a \
\( "${ext_sig_pos}" -lt "${ext_sig_cnt}" \) ] || {
skip="${next_skip}"
next_skip=0
continue
}
[ 0 != "$datasz" ] || datasz=2000
[ 0 != "$totalsz" ] || totalsz=2048
# ext_sig, 12 bytes in size
IFS=' ' read cpuid pf_mask <<- EOF
$(hexdump -s "$skip" -n 8 \
-e '"" 1/4 "%08x " 1/4 "%u" "\n"' "$f")
EOF
# TODO: add some sanity/safety checks here. As of now, there's
# a (pretty fragile) assumption that all the matched files
# are valid Intel microcode files in the expected format.
skip="$((skip + 12))"
ext_sig_pos="$((ext_sig_pos + 1))"
else
# Microcode header, 48 bytes, last 3 fields reserved
IFS=' ' read hdrver rev \
date_y date_d date_m \
cpuid cksum ldrver \
pf_mask datasz totalsz <<- EOF
$(hexdump -s "$skip" -n 36 \
-e '"" 1/4 "%u " 1/4 "%#x " \
1/2 "%04x " 1/1 "%02x " 1/1 "%02x " \
1/4 "%08x " 1/4 "%x " 1/4 "%#x " \
1/4 "%u " 1/4 "%u " 1/4 "%u" "\n"' "$f")
EOF
skip=$((skip + totalsz))
[ 0 != "$datasz" ] || datasz=2000
[ 0 != "$totalsz" ] || totalsz=2048
# TODO: add some sanity/safety checks here. As of now,
# there's a (pretty fragile) assumption that all
# the matched files are valid Intel microcode
# files in the expected format.
# ext_sig table is after the microcode payload,
# check for its presence
if [ 48 -lt "$((totalsz - datasz))" ]; then
next_skip="$((skip + totalsz))"
skip="$((skip + datasz + 48))"
ext_sig_pos=0
# ext_sig table header, 20 bytes in size,
# last 3 fields are reserved.
IFS=' ' read ext_sig_cnt <<- EOF
$(hexdump -s "$skip" -n 4 \
-e '"" 1/4 "%u" "\n"' "$f")
EOF
skip="$((skip + 20))"
else
skip="$((skip + totalsz))"
next_skip=0
fi
fi
#[ -n "$rev" ] || continue

View File

@ -1,5 +1,5 @@
path intel-ucode/*
vendor_id GenuineIntel
vendor GenuineIntel
kernel_early 4.10.0
kernel_early 3.10.0-930
kernel_early 3.10.0-862.14.1

View File

@ -1,5 +1,4 @@
%define intel_ucode_version 20191115
%define intel_ucode_file_id 28727
%define intel_ucode_version 20200609
%global debug_package %{nil}
%define caveat_dir %{_datarootdir}/microcode_ctl/ucode_with_caveats
@ -14,10 +13,10 @@
Summary: CPU microcode updates for Intel x86 processors
Name: microcode_ctl
Version: %{intel_ucode_version}
Release: 4%{?dist}
Release: 2%{?dist}
Epoch: 4
License: CC0 and Redistributable, no modification permitted
URL: https://downloadcenter.intel.com/download/%{intel_ucode_file_id}/Linux-Processor-Microcode-Data-File
URL: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
Source0: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-%{intel_ucode_version}.tar.gz
# (Pre-MDS) revision 0x714 of 06-2d-07 microcode
@ -26,6 +25,15 @@ Source2: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Fi
# (Pre-20191112) revision 0x2000064 of 06-55-04 microcode
Source3: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/raw/microcode-20190918/intel-ucode/06-55-04
# (Pre-20200609) revision 0xd6 of 06-4e-03/06-5e-03 microcode
Source4: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/raw/microcode-20200520/intel-ucode/06-4e-03
Source5: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/raw/microcode-20200520/intel-ucode/06-5e-03
# microcode-20190918 release,containing revision 0xb4/0xb8 of 06-[89]e-0X microcode
Source6: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20190918.tar.gz
# microcode-20191115 release,containing revision 0xca of 06-[89]e-0X microcode
Source7: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz
# systemd unit
Source10: microcode.service
@ -71,16 +79,50 @@ Source130: 06-55-04_readme
Source131: 06-55-04_config
Source132: 06-55-04_disclaimer
# SKL-U/Y (CPUID 0x406e3) post-20200609 hangs
# https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
Source140: 06-4e-03_readme
Source141: 06-4e-03_config
Source142: 06-4e-03_disclaimer
# SKL-H/S/Xeon E3 v5 (CPUID 0x506e3) post-20200609 possible hangs
# https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-644885826
Source150: 06-5e-03_readme
Source151: 06-5e-03_config
Source152: 06-5e-03_disclaimer
# Dell 06-[89]e-0x hangs - intermediate 0xca microcode revision
# https://bugzilla.redhat.com/show_bug.cgi?id=1807960
# https://bugzilla.redhat.com/show_bug.cgi?id=1846097
# https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/23
# https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/24
# https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1862751
Source160: 06-8e-9e-0x-0xca_readme
Source161: 06-8e-9e-0x-0xca_config
Source162: 06-8e-9e-0x-0xca_disclaimer
# Dell 06-[89]e-0x hangs - latest microcode revision
# https://bugzilla.redhat.com/show_bug.cgi?id=1807960
# https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/33
# https://bugs.debian.org/962757
# https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1882943
Source170: 06-8e-9e-0x-dell_readme
Source171: 06-8e-9e-0x-dell_config
Source172: 06-8e-9e-0x-dell_disclaimer
# "Provides:" RPM tags generator
Source200: gen_provides.sh
ExclusiveArch: %{ix86} x86_64
BuildRequires: systemd-units
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
Requires(posttrans): dracut
# hexdump is used in gen_provides.sh
BuildRequires: coreutils util-linux
Requires: coreutils
Requires(post): systemd coreutils
Requires(preun): systemd coreutils
Requires(postun): systemd coreutils
Requires(posttrans): dracut coreutils
%global _use_internal_dependency_generator 0
%define __find_provides "%{SOURCE200}"
@ -107,6 +149,26 @@ cp "%{SOURCE2}" intel-ucode/
mv intel-ucode/06-55-04 intel-ucode-with-caveats/
cp "%{SOURCE3}" intel-ucode/
# replacing SKL-U/Y (CPUID 0x4063e) microcode with pre-20200609 version
mv intel-ucode/06-4e-03 intel-ucode-with-caveats/
cp "%{SOURCE4}" intel-ucode/
# replacing SKL-H/S/Xeon E3 v5 (CPUID 0x5063e) microcode with pre-20200609 version
mv intel-ucode/06-5e-03 intel-ucode-with-caveats/
cp "%{SOURCE5}" intel-ucode/
# Replacing the latest 06-[89]e-0x caveat with pre-20191112 version
mv intel-ucode/06-[89]e-0* intel-ucode-with-caveats/
tar xvvf "%{SOURCE6}" --wildcards --strip-components=1 \
'*/intel-ucode/06-[89]e-0*'
# Unpacking intermediate 06-[89]e-0x microcode revision 0xca (from microcode-20191115)
mkdir -p intel-ucode-0xca
pushd intel-ucode-0xca
tar xvvf "%{SOURCE7}" --wildcards --strip-components=2 \
'*/intel-ucode/06-[89]e-0*'
popd
:
%install
@ -151,6 +213,7 @@ install -m 644 releasenote \
# caveats
install -m 644 "%{SOURCE100}" "%{SOURCE110}" "%{SOURCE120}" "%{SOURCE130}" \
"%{SOURCE140}" "%{SOURCE150}" "%{SOURCE160}" "%{SOURCE170}" \
-t "%{buildroot}/%{_pkgdocdir}/caveats/"
@ -181,12 +244,44 @@ install -m 644 "%{SOURCE121}" "%{snb_inst_dir}/config"
install -m 644 "%{SOURCE122}" "%{snb_inst_dir}/disclaimer"
# SKL-SP caveat
%define skl_inst_dir %{buildroot}/%{caveat_dir}/intel-06-55-04/
install -m 755 -d "%{skl_inst_dir}/intel-ucode"
install -m 644 intel-ucode-with-caveats/06-55-04 -t "%{skl_inst_dir}/intel-ucode/"
install -m 644 "%{SOURCE130}" "%{skl_inst_dir}/readme"
install -m 644 "%{SOURCE131}" "%{skl_inst_dir}/config"
install -m 644 "%{SOURCE132}" "%{skl_inst_dir}/disclaimer"
%define skl_sp_inst_dir %{buildroot}/%{caveat_dir}/intel-06-55-04/
install -m 755 -d "%{skl_sp_inst_dir}/intel-ucode"
install -m 644 intel-ucode-with-caveats/06-55-04 -t "%{skl_sp_inst_dir}/intel-ucode/"
install -m 644 "%{SOURCE130}" "%{skl_sp_inst_dir}/readme"
install -m 644 "%{SOURCE131}" "%{skl_sp_inst_dir}/config"
install -m 644 "%{SOURCE132}" "%{skl_sp_inst_dir}/disclaimer"
# SKL-U/Y caveat
%define skl_uy_inst_dir %{buildroot}/%{caveat_dir}/intel-06-4e-03/
install -m 755 -d "%{skl_uy_inst_dir}/intel-ucode"
install -m 644 intel-ucode-with-caveats/06-4e-03 -t "%{skl_uy_inst_dir}/intel-ucode/"
install -m 644 "%{SOURCE140}" "%{skl_uy_inst_dir}/readme"
install -m 644 "%{SOURCE141}" "%{skl_uy_inst_dir}/config"
install -m 644 "%{SOURCE142}" "%{skl_uy_inst_dir}/disclaimer"
# SKL-H/S/Xeoon E3 v5 caveat
%define skl_hs_inst_dir %{buildroot}/%{caveat_dir}/intel-06-5e-03/
install -m 755 -d "%{skl_hs_inst_dir}/intel-ucode"
install -m 644 intel-ucode-with-caveats/06-5e-03 -t "%{skl_hs_inst_dir}/intel-ucode/"
install -m 644 "%{SOURCE150}" "%{skl_hs_inst_dir}/readme"
install -m 644 "%{SOURCE151}" "%{skl_hs_inst_dir}/config"
install -m 644 "%{SOURCE152}" "%{skl_hs_inst_dir}/disclaimer"
# Dell 06-[89]e-0x 0xca caveat
%define dell_0xca_inst_dir %{buildroot}/%{caveat_dir}/intel-06-8e-9e-0x-0xca/
install -m 755 -d "%{dell_0xca_inst_dir}/intel-ucode"
install -m 644 intel-ucode-0xca/06-[89]e-0? -t "%{dell_0xca_inst_dir}/intel-ucode/"
install -m 644 "%{SOURCE160}" "%{dell_0xca_inst_dir}/readme"
install -m 644 "%{SOURCE161}" "%{dell_0xca_inst_dir}/config"
install -m 644 "%{SOURCE162}" "%{dell_0xca_inst_dir}/disclaimer"
# Dell 06-[89]e-0x latest caveat
%define dell_latest_inst_dir %{buildroot}/%{caveat_dir}/intel-06-8e-9e-0x-dell/
install -m 755 -d "%{dell_latest_inst_dir}/intel-ucode"
install -m 644 intel-ucode-with-caveats/06-[89]e-0? -t "%{dell_latest_inst_dir}/intel-ucode/"
install -m 644 "%{SOURCE170}" "%{dell_latest_inst_dir}/readme"
install -m 644 "%{SOURCE171}" "%{dell_latest_inst_dir}/config"
install -m 644 "%{SOURCE172}" "%{dell_latest_inst_dir}/disclaimer"
%post
@ -211,21 +306,121 @@ exit 0
# dependency, it is pointless at best to regenerate the initramfs,
# and also does not work with rpm-ostree:
# https://bugzilla.redhat.com/show_bug.cgi?id=1199582
# https://bugzilla.redhat.com/show_bug.cgi?id=1530400
[ -d /run/systemd/system ] || exit 0
# We can't simply update all initramfs images, since "dracut --regenerate-all"
# generates initramfs even for removed kernels and if dracut generates botched
# initramfs image, that results in unbootable system, even with older kernels
# that can't be used as a fallback:
# https://bugzilla.redhat.com/show_bug.cgi?id=1420180
# https://access.redhat.com/support/cases/#/case/01779274
# https://access.redhat.com/support/cases/#/case/01814106
#
# Also check that the running kernel is actually installed:
# https://bugzilla.redhat.com/show_bug.cgi?id=1591664
# We use the presence of symvers file as an indicator, the check similar
# to what weak-modules script does.
# ...and we can't simply limit ourselves to updating only the currently
# running kernel, as this doesn't work well with cases where kernel
# is installed before the updated microcode, or in the same transaction.
# And we can't rely on late update either, due to issues like this:
# https://bugzilla.redhat.com/show_bug.cgi?id=1710445
#
# Now that /boot/symvers-KVER.gz population is now relies on some shell scripts
# that are triggered by other shell scripts (kernel-install, which is a part
# of systemd) that called by RPM scripts, and systemd is not inclined to fix
# https://bugzilla.redhat.com/show_bug.cgi?id=1609698
# https://bugzilla.redhat.com/show_bug.cgi?id=1609696
# So, we check for symvers file inside /lib/modules.
if [ -d /run/systemd/system -a -e "/lib/modules/$(uname -r)/symvers.gz" ]; then
dracut -f
fi
# ...and there are also issues with setups with increased "installonly_limit"
# in /etc/yum.conf, which could lead to unacceptably long package installation
# times.
#
# So, in the end, we try to grab no more than 2 most recently installed kernels
# that are installed after the currently running one (with the currently running
# kernel that makes up to 3 in total, the default "installonly_limit" value)
# as a kernel package selection heuristic that tries to accomodate both the need
# to put the latest microcode in freshly installed kernels and also addresses
# existing concerns.
#
# For RPM selection, kernel flavours (like "debug" or "kdump" or "zfcp",
# with only the former being relevant to x86 architecture) are a part or RPM
# name; it's also a part of uname, with different separator used in RHEL 6/7
# and RHEL 8. RT kernel, however, is special, as "rt" is another part
# of RPM name and it has its own versioning scheme both in NVR and uname.
# And there's the kernel package split in RHEL 8, so one should look for *-core
# and not the main package.
pkgs="kernel-core kernel-debug-core kernel-rt-core kernel-rt-debug-core"
qf='%%{NAME} %%{VERSION}-%%{RELEASE}.%%{ARCH} %%{installtime}\n'
: "${MICROCODE_RPM_KVER_LIMIT=2}"
rpm -qa --qf "${qf}" ${pkgs} | sort -r -n -k'3,3' | {
kver_cnt=0
processed=""
skipped=""
skip=0
while read -r pkgname vra install_ts; do
flavour=''
# For x86, only "debug" flavour exists in RHEL 8
[ "x${pkgname%*-debug-core}" = "x${pkgname}" ] \
|| flavour='+debug'
kver_cnt="$((kver_cnt + 1))"
kver_uname="${vra}${flavour}"
# Also check that the kernel is actually installed:
# https://bugzilla.redhat.com/show_bug.cgi?id=1591664
# We use the presence of symvers file as an indicator, the check
# similar to what weak-modules script does.
#
# Now that /boot/symvers-KVER.gz population is now relies
# on some shell scripts that are triggered by other shell
# scripts (kernel-install, which is a part of systemd) that
# called by RPM scripts, and systemd is not inclined to fix
# https://bugzilla.redhat.com/show_bug.cgi?id=1609698
# https://bugzilla.redhat.com/show_bug.cgi?id=1609696
# So, we check for symvers file inside /lib/modules.
#
# XXX: Not sure if this check is still needed, since we now
# iterate over the rpm output.
[ -e "/lib/modules/${kver_uname}/symvers.gz" ] || continue
# Check that modules.dep for the kernel is present as well,
# otherwise dracut complains with "/lib/modules/.../modules.dep
# is missing. Did you run depmod?".
[ -e "/lib/modules/${kver_uname}/modules.dep" ] || continue
# We update the kernels with the same uname as the running kernel
# regardless of the selected limit
if [ "x$(uname -r)" = "x${kver_uname}" \
-o \( "${kver_cnt}" -le "${MICROCODE_RPM_KVER_LIMIT}" \
-a "${skip}" = 0 \) ]
then
dracut -f --kver "${kver_uname}"
processed="${processed} ${pkgname}-${vra}"
else
skipped="${skipped} ${pkgname}-${vra}"
fi
# The packages are processed until a package with the same uname
# as the running kernel is hit (since they are sorted
# in the descending installation time stamp older).
[ "x$(uname -r)" != "x${kver_uname}" ] || skip=1
done
if [ -n "${skipped}" ]; then
skip_msg="After installation of a new version of microcode_ctl package,
initramfs hasn't been re-generated for all the installed kernel packages.
The following kernel packages have been skipped:${skipped}.
Please re-generate initramfs manually for these kernel packages with the
\"dracut -f --kver KERNEL_VERSION\" command in order to get the latest
Intel CPU microcode included into early initramfs image for it, if needed."
if [ -e /usr/bin/logger ]; then
echo "${skip_msg}" |
/usr/bin/logger -p syslog.notice -t microcode_ctl
fi
if [ -e /dev/kmsg ]; then
echo "${skip_msg}" > /dev/kmsg
fi
fi
}
exit 0
%global rpm_state_dir %{_localstatedir}/lib/rpm-state
@ -318,6 +513,95 @@ rm -rf %{buildroot}
%changelog
* Mon Jun 22 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200609-2
- Blacklist latest microcode revision for 06-[89]e-0x CPUs (AML-Y,
CFL-H/S/U/Xeon E, CML-Y, KBL-G/H/S/X/U/Y/Xeon E3 v6, WHL-U) on Dell systems,
use revision 0xae/0xb4/0xb8 by default, provide the latest revision
and intermediate revision 0xca in caveats (#1807960, #1846097).
* Mon Jun 15 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200609-1
- Update Intel CPU microcode to microcode-20200609 release (#1845967):
- Fixed a typo in the release note file.
* Mon Jun 15 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200602-5
- Enable 06-2d-07 (SNB-E/EN/EP) caveat by default.
* Mon Jun 15 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200602-4
- Enable 06-55-04 (SKL-X/W) caveat by default.
* Sun Jun 14 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200602-3
- Do not update 06-4e-03 (SKL-U/Y) and 06-5e-03 (SKL-H/S/Xeon E3 v5) to revision
0xdc, use 0xd6 by default (#1846119).
* Thu Jun 04 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200602-2
- Avoid temporary file creation, used for here-documents in check_caveats
(#1839163).
* Wed Jun 03 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200602-1
- Update Intel CPU microcode to microcode-20200602 release, addresses
CVE-2020-0543, CVE-2020-0548, CVE-2020-0549 (#1795354, #1795356, #1827184):
- Update of 06-3c-03/0x32 (HSW C0) microcode from revision 0x27 up to 0x28;
- Update of 06-3d-04/0xc0 (BDW-U/Y E0/F0) microcode from revision 0x2e
up to 0x2f;
- Update of 06-45-01/0x72 (HSW-U C0/D0) microcode from revision 0x25
up to 0x26;
- Update of 06-46-01/0x32 (HSW-H C0) microcode from revision 0x1b up to 0x1c;
- Update of 06-47-01/0x22 (BDW-H/Xeon E3 E0/G0) microcode from revision 0x21
up to 0x22;
- Update of 06-4e-03/0xc0 (SKL-U/Y D0) microcode from revision 0xd6
up to 0xdc;
- Update of 06-55-03/0x97 (SKX-SP B1) microcode from revision 0x1000151
up to 0x1000157;
- Update of 06-55-04/0xb7 (SKX-SP H0/M0/U0, SKX-D M1) microcode
(in intel-06-55-04/intel-ucode/06-55-04) from revision 0x2000065
up to 0x2006906;
- Update of 06-55-06/0xbf (CLX-SP B0) microcode from revision 0x400002c
up to 0x4002f01;
- Update of 06-55-07/0xbf (CLX-SP B1) microcode from revision 0x500002c
up to 0x5002f01;
- Update of 06-5e-03/0x36 (SKL-H/S R0/N0) microcode from revision 0xd6
up to 0xdc;
- Update of 06-8e-09/0x10 (AML-Y22 H0) microcode from revision 0xca
up to 0xd6;
- Update of 06-8e-09/0xc0 (KBL-U/Y H0) microcode from revision 0xca
up to 0xd6;
- Update of 06-8e-0a/0xc0 (CFL-U43e D0) microcode from revision 0xca
up to 0xd6;
- Update of 06-8e-0b/0xd0 (WHL-U W0) microcode from revision 0xca
up to 0xd6;
- Update of 06-8e-0c/0x94 (AML-Y42 V0, CML-Y42 V0, WHL-U V0) microcode
from revision 0xca up to 0xd6;
- Update of 06-9e-09/0x2a (KBL-G/H/S/X/Xeon E3 B0) microcode from revision
0xca up to 0xd6;
- Update of 06-9e-0a/0x22 (CFL-H/S/Xeon E3 U0) microcode from revision 0xca
up to 0xd6;
- Update of 06-9e-0b/0x02 (CFL-S B0) microcode from revision 0xca up to 0xd6;
- Update of 06-9e-0c/0x22 (CFL-H/S P0) microcode from revision 0xca
up to 0xd6;
- Update of 06-9e-0d/0x22 (CFL-H R0) microcode from revision 0xca up to 0xd6.
* Fri May 22 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200520-1
- Update Intel CPU microcode to microcode-20200520 release (#1783103):
- Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0) microcode from revision 0x61f
up to 0x621;
- Update of 06-2d-07/0x6d (SNB-E/EN/EP C2/M1) microcode from revision 0x718
up to 0x71a.
* Tue May 12 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20200508-1
- Update Intel CPU microcode to microcode-20200508 release (#1783103):
- Update of 06-7e-05/0x80 (ICL-U/Y D1) microcode from revision 0x46
up to 0x78.
- Change the URL to point to the GitHub repository since the microcode download
section at Intel Download Center does not exist anymore.
* Thu May 07 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20191115-6
- Narrow down SKL-SP/W/X blacklist to exclude Server/FPGA/Fabric segment
models (#1833036).
* Wed Apr 29 2020 Eugene Syromiatnikov <esyr@redhat.com> - 4:20191115-5
- Re-generate initramfs not only for the currently running kernel,
but for several recently installed kernels as well (#1773338).
* Mon Dec 09 2019 Eugene Syromiatnikov <esyr@redhat.com> - 4:20191115-4
- Avoid find being SIGPIPE'd on early "grep -q" exit in the dracut script
(#1781365).