| Summary: | Update request: microcode-0.20190514-1.mga6.nonfree | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Thomas Backlund <tmb> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | critical | ||
| Priority: | High | CC: | davidwhodgins, fri, jim, sysadmin-bugs, tarazed25 |
| Version: | 6 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA6-64-OK, MGA6-32-OK | ||
| Source RPM: | microcode | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 24774, 24775, 24820 | ||
|
Description
Thomas Backlund
2019-05-12 15:50:42 CEST
Installed this on main testing machine; x86_64, quadcore HT. Rebooted. $ rpm -qa | grep microcode microcode_ctl-2.1-7.mga6 microcode-0.20190312-1.mga6.nonfree $ dmesg | grep microcode [ 0.000000] microcode: microcode updated early to revision 0x25, date = 2018-04-02 [ 0.421696] microcode: sig=0x306c3, pf=0x2, revision=0x25 [ 0.421977] microcode: Microcode Update Driver: v2.2. # journalctl -xb | grep microcode May 13 20:56:42 difda kernel: microcode: microcode updated early to revision 0x25, date = 2018-04-02 May 13 20:56:42 difda kernel: microcode: sig=0x306c3, pf=0x2, revision=0x25 May 13 20:56:42 difda kernel: microcode: Microcode Update Driver: v2.2. Is that date correct? It looks rather old. CC:
(none) =>
tarazed25 x86_64, Skylake system Before update journalctl shows: May 13 23:24:20 canopus kernel: microcode: microcode updated early to revision 0x200004d, date = 2018-05-15 May 13 23:24:20 canopus kernel: microcode: sig=0x50654, pf=0x4, revision=0x200004d May 13 23:24:20 canopus kernel: microcode: Microcode Update Driver: v2.2. After update: Reboot # journalctl -xb | grep microcode May 13 23:34:49 canopus kernel: microcode: microcode updated early to revision 0x200005a, date = 2019-01-28 May 13 23:34:49 canopus kernel: microcode: sig=0x50654, pf=0x4, revision=0x200005a May 13 23:34:49 canopus kernel: microcode: Microcode Update Driver: v2.2. That looks better. And going again... this is now part of the MDS security update going public today a few hours ago... (S)RPM: microcode-0.20190514-1.mga6.nonfree And its a _BIG_ update, all the way from Intel Sandy Bridge... Changelog: - Intel Microcode updates: - new platforms * VLV C0 6-37-8/02 00000838 Atom Z series * VLV C0 6-37-8/0C 00000838 Celeron N2xxx, Pentium N35xx * VLV D0 6-37-9/0F 0000090c Atom E38xx * CHV C0 6-4c-3/01 00000368 Atom X series * CHV D0 6-4c-4/01 00000411 Atom X series * CLX-SP B1 6-55-7/bf 05000021 Xeon Scalable Gen2 - updated platforms * SNB D2/G1/Q0 6-2a-7/12 0000002e->0000002f Core Gen2 * IVB E1/L1 6-3a-9/12 00000020->00000021 Core Gen3 * HSW C0 6-3c-3/32 00000025->00000027 Core Gen4 * BDW-U/Y E0/F0 6-3d-4/c0 0000002b->0000002d Core Gen5 * IVB-E/EP C1/M1/S1 6-3e-4/ed 0000042e->0000042f Core Gen3 X Series; Xeon E5 v2 * IVB-EX D1 6-3e-7/ed 00000714->00000715 Xeon E7 v2 * HSX-E/EP Cx/M1 6-3f-2/6f 00000041->00000043 Core Gen4 X series; Xeon E5 v3 * HSX-EX E0 6-3f-4/80 00000013->00000014 Xeon E7 v3 * HSW-U C0/D0 6-45-1/72 00000024->00000025 Core Gen4 * HSW-H C0 6-46-1/32 0000001a->0000001b Core Gen4 * BDW-H/E3 E0/G0 6-47-1/22 0000001e->00000020 Core Gen5 * SKL-U/Y D0/K1 6-4e-3/c0 000000c6->000000cc Core Gen6 * BDX-ML B0/M0/R0 6-4f-1/ef 0b00002e->00000036 Xeon E5/E7 v4; Core i7-69xx/68xx * SKX-SP H0/M0/U0 6-55-4/b7 0200005a->0000005e Xeon Scalable * SKX-D M1 6-55-4/b7 0200005a->0000005e Xeon D-21xx * BDX-DE V1 6-56-2/10 00000019->0000001a Xeon D-1520/40 * BDX-DE V2/3 6-56-3/10 07000016->07000017 Xeon D-1518/19/21/27/28/31/33/37/41/48, Pentium D1507/08/09/17/19 * BDX-DE Y0 6-56-4/10 0f000014->0f000015 Xeon D-1557/59/67/71/77/81/87 * BDX-NS A0 6-56-5/10 0e00000c->0e00000d Xeon D-1513N/23/33/43/53 * APL D0 6-5c-9/03 00000036->00000038 Pentium N/J4xxx, Celeron N/J3xxx, Atom x5/7-E39xx * SKL-H/S R0/N0 6-5e-3/36 000000c6->000000cc Core Gen6; Xeon E3 v5 * DNV B0 6-5f-1/01 00000024->0000002e Atom C Series * GLK B0 6-7a-1/01 0000002c->0000002e Pentium Silver N/J5xxx, Celeron N/J4xxx * AML-Y22 H0 6-8e-9/10 0000009e->000000b4 Core Gen8 Mobile * KBL-U/Y H0 6-8e-9/c0 0000009a->000000b4 Core Gen7 Mobile * CFL-U43e D0 6-8e-a/c0 0000009e->000000b4 Core Gen8 Mobile * WHL-U W0 6-8e-b/d0 000000a4->000000b8 Core Gen8 Mobile * WHL-U V0 6-8e-d/94 000000b2->000000b8 Core Gen8 Mobile * KBL-G/H/S/E3 B0 6-9e-9/2a 0000009a->000000b4 Core Gen7; Xeon E3 v6 * CFL-H/S/E3 U0 6-9e-a/22 000000aa->000000b4 Core Gen8 Desktop, Mobile, Xeon E * CFL-S B0 6-9e-b/02 000000aa->000000b4 Core Gen8 * CFL-H/S P0 6-9e-c/22 000000a2->000000ae Core Gen9 * CFL-H R0 6-9e-d/22 000000b0->000000b8 Core Gen9 Mobile Component:
RPM Packages =>
Security This one should go out before the 4.14.119 series kernels (or at the same time) Blocks:
(none) =>
24774, 24775, 24820 Ok on my x86_64 Mageia 6 system with an amd cpu and vb guests on that system, both i586 and x86_64 Mageia 6 guests. CC:
(none) =>
davidwhodgins Intel Core i7-4790 (-HT-MCP-) mga6, x86_64 $ dmesg | grep microcode [ 0.000000] microcode: microcode updated early to revision 0x27, date = 2019-02-26 [ 0.424500] microcode: sig=0x306c3, pf=0x2, revision=0x27 [ 0.424842] microcode: Microcode Update Driver: v2.2. Kernel testing later. Intel Core i9-7900X (-HT-MCP-) mga6, x86_64 $ dmesg | grep microcode [ 0.000000] microcode: microcode updated early to revision 0x200005e, date = 2019-04-02 [ 0.703658] microcode: sig=0x50654, pf=0x4, revision=0x200005e [ 0.703949] microcode: Microcode Update Driver: v2.2. on mga6-64 plasma
$ rpm -q microcode
microcode-0.20190514-1.mga6.nonfree
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0xcc, date =
2019-04-01
[ 0.543372] microcode: sig=0x506e3, pf=0x2, revision=0xcc
[ 0.543640] microcode: Microcode Update Driver: v2.2.
OK for mga6-64 on this system:
Machine: Device: desktop System: Dell product: Precision Tower 3620
Mobo: Dell model: 09WH54 v: A00 UEFI [Legacy]: Dell v: 2.12.0 date:
02/15/2019
CPU: Quad core Intel Core i7-6700 (-HT-MCP-)CC:
(none) =>
jim 64 bit OK here Hardware: Quad core (8 threads) i7-2600K, Nvidia GTX760 (GK104) using proprietary driver GeForce 420 and later, with CUDA & OpenCL detected OK in BOINC (bot not used), / & /home & swap in LVM on LUKS on SSD $ uname -a Linux svarten 4.14.119-desktop-1.mga6 #1 SMP Tue May 14 19:26:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux bash-4.3$ rpm -q microcode microcode-0.20190514-1.mga6.nonfree bash-4.3$ dmesg | grep microcode [ 0.609367] microcode: sig=0x206a7, pf=0x2, revision=0x2f [ 0.609631] microcode: Microcode Update Driver: v2.2. CC:
(none) =>
fri
Advisory, added to svn:
type: security
subject: Updated microcode packages fix security vulnerabilities
CVE:
- CVE-2018-12126
- CVE-2018-12127
- CVE-2018-12130
- CVE-2019-11091
src:
6:
nonfree:
- microcode-0.20190514-1.mga6.nonfree
description: |
This update provides the Intel 20190514 microcode release that adds the
microcode side mitigations for the Microarchitectural Data Sampling (MDS,
also called ZombieLoad attack) vulnerabilities in Intel processors that
can allow attackers to retrieve data being processed inside a CPU.
The fixed / mitigated issues are:
Modern Intel microprocessors implement hardware-level micro-optimizations
to improve the performance of writing data back to CPU caches. The write
operation is split into STA (STore Address) and STD (STore Data)
sub-operations. These sub-operations allow the processor to hand-off
address generation logic into these sub-operations for optimized writes.
Both of these sub-operations write to a shared distributed processor
structure called the 'processor store buffer'. As a result, an
unprivileged attacker could use this flaw to read private data resident
within the CPU's processor store buffer. (CVE-2018-12126)
Microprocessors use a ‘load port’ subcomponent to perform load operations
from memory or IO. During a load operation, the load port receives data
from the memory or IO subsystem and then provides the data to the CPU
registers and operations in the CPU’s pipelines. Stale load operations
results are stored in the 'load port' table until overwritten by newer
operations. Certain load-port operations triggered by an attacker can be
used to reveal data about previous stale requests leaking data back to the
attacker via a timing side-channel. (CVE-2018-12127)
A flaw was found in the implementation of the "fill buffer", a mechanism
used by modern CPUs when a cache-miss is made on L1 CPU cache. If an
attacker can generate a load operation that would create a page fault,
the execution will continue speculatively with incorrect data from the
fill buffer while the data is fetched from higher level caches. This
response time can be measured to infer data in the fill buffer.
(CVE-2018-12130)
Uncacheable memory on some microprocessors utilizing speculative execution
may allow an authenticated user to potentially enable information disclosure
via a side channel with local access. (CVE-2019-11091)
references:
- https://bugs.mageia.org/show_bug.cgi?id=24800
- https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.htmlKeywords:
(none) =>
advisory Enough tests as its also in Cauldron, flushing it out Whiteboard:
(none) =>
MGA6-64-OK, MGA6-32-OK An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0173.html Resolution:
(none) =>
FIXED |