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
Summary: Update request: microcode-0.20190312-1.mga6.nonfree => Update request: microcode-0.20190514-1.mga6.nonfree
QA Contact: (none) => security
Severity: normal => critical
Priority: Normal => High

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.html

Keywords: (none) => advisory

Enough tests as its  also in Cauldron, flushing it out

Whiteboard: (none) => MGA6-64-OK, MGA6-32-OK
Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0173.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED