Bug 1411232

The buggy update was released in 7.3.z as RHBA-2017:0028-04 microcode_ctl bug fix update. So the fix needs to go to 7.3.z as well.

This bug should not affect functionality as the expected CPU microcode is still loaded by the rpm %post script:

 49         grep -l GenuineIntel /proc/cpuinfo | xargs grep -l "model.*79" > /dev/null || \
 50         echo 1 > /sys/devices/system/cpu/microcode/reload

However the failed systemd service still needs to be fixed.

*** Bug 1411718 has been marked as a duplicate of this bug. ***

Harald,
On the next boot microcode is updated from the dracut image. This is done because, in some cases, microcode cannot be updated on a running system.

*** Bug 1412173 has been marked as a duplicate of this bug. ***

That grep looks a bit suspect to me. That will almost certainly match on an i7-4790k from the 

model name	: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

and that has 

model		: 60

Would be better as:

ExecStart=/usr/bin/bash -c 'grep -l GenuineIntel /proc/cpuinfo | xargs grep -l -P "model\t.*79$" > /dev/null || echo 1 > /sys/devices/system/cpu/microcode/reload'

Good catch,
Fixed in last respin microcode_ctl-2.1-20.el7

Exactly same regexp problem is in %post script.

If the intention is to update only Intel CPUs, then the suggested statement does not work, because xargs returns an error if it can't read anything from stdin.

Example with an AMD CPU:

# cat /proc/cpuinfo  | head -n 2
processor : 0
vendor_id : AuthenticAMD

# grep -l GenuineIntel /proc/cpuinfo | xargs grep -l -P "model\t.*79$" > /dev/null || echo 1
1

No, this is for update all cpu's but expression exclude from update intel cpu model 79.

Would it be possible to use a better readable statement or to add a commend in top of the statement to show the intention (all but model 79)?

hi:
   May I ask since microcode already applied via dracut image, why we need systemd service to load it again?

tbsky,
In most cases the systemd service isn't necessary, that's why this bug is really not critical. It's there mostly for safety reasons, if you build your own initramfs and forget to include the updated microcode file, the service might help in updating the microcode during boot. Obviously this isn't sufficient solution because in some cases the microcode needs to be updated before glibc is loaded, that is from initramfs. You should really make sure the initramfs contains the proper microcode. Thanks!

*** Bug 1425109 has been marked as a duplicate of this bug. ***

Based on the comments #25, #31 and #32 I propose to change it as

ExecStart=/usr/bin/bash -c 'grep -l GenuineIntel /proc/cpuinfo | xargs grep -q "model[[:blank:]]*: 79$" || echo 1 > /sys/devices/system/cpu/microcode/reload'

this would execute 
   echo 1 > /sys/devices/system/cpu/microcode/reload

for any
 - non GenuineIntel CPU
 - GenuineIntel CPU, except the one with "model    : 79"

I have to agree w/ Harald that this is one of the ungodliest kludges I have ever seen.  

First, yes, it should have been put in an auxiliary script rather than being shoehorned in with 'bash -c'.  But even more so, what is that horrible shell construct?  Grep for 'GenuineIntel' in /proc/cpuinfo and return the name of the file if it matches, then xargs that into grepping for 'model 79' in whatever file might have had a match from the first grep (gee, might it have been /proc/cpuinfo?), tossing away any matches found into /dev/null and then if that found nothing, then do the echo...

If you're going to try to use a one-(long-)line shell construct (and including robustifying the grep patterns, which Frank started, but didn't carry far enough) how about something much more straightforward like this:

  grep -q '^vendor_id[[:blank:]]*: GenuineIntel$' /proc/cpuinfo \
    && grep -q '^model[[:blank:]]*: 79$' /proc/cpuinfo \
      || echo 1 > /sys/devices/system/cpu/microcode/reload

Note that I'm not worrying here how to further quote and escape this to be able to wrap it in 'bash -c' and place that in an ExecStart= line -- all the more reason to put whatever one decides to use inside an auxiliary script file!

Hello,

The fix for RHEL-7.3.z has been released yesterday under bz1412187. Please review following Errata with the details:
https://rhn.redhat.com/errata/RHBA-2017-0374.html

Thanks.

ALL TESTS PASSED

Verified as fixed in microcode_ctl-2.1-20.el7, the service now loads without errors

Before
======================
~]# rpm -qa microcode_ctl
microcode_ctl-2.1-16.1.el7_3.x86_64

~]# systemctl status microcode -l
● microcode.service - Load CPU microcode update
   Loaded: error (Reason: Invalid argument)
   Active: inactive (dead) since Fri 2017-05-05 18:24:00 EDT; 3h 41min left
 Main PID: 725 (code=exited, status=0/SUCCESS)

May 05 18:23:59 localhost.localdomain systemd[1]: Starting Load CPU microcode update...
May 05 18:24:00 localhost.localdomain systemd[1]: Started Load CPU microcode update.
May 05 14:41:06 dell-per210-01.khw.lab.eng.bos.redhat.com systemd[1]: [/usr/lib/systemd/system/microcode.service:10] Trailing garbage, ignoring.
May 05 14:41:06 dell-per210-01.khw.lab.eng.bos.redhat.com systemd[1]: microcode.service lacks both ExecStart= and ExecStop= setting. Refusing.
~]# 

After
======================
~]# yum update microcode_ctl-2.1-20.el7.x86_64.rpm

~]# rpm -qa microcode_ctl
microcode_ctl-2.1-20.el7.x86_64

~]# systemctl restart microcode

~]# systemctl status microcode -l
● microcode.service - Load CPU microcode update
   Loaded: loaded (/usr/lib/systemd/system/microcode.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Fri 2017-05-05 14:44:18 EDT; 30s ago
  Process: 29163 ExecStart=/usr/bin/bash -c grep -l GenuineIntel /proc/cpuinfo | xargs grep -l -E "model[[:space:]]*: 79$" > /dev/null || echo 1 > /sys/devices/system/cpu/microcode/reload (code=exited, status=0/SUCCESS)
 Main PID: 29163 (code=exited, status=0/SUCCESS)

May 05 14:44:18 dell-per210-01.khw.lab.eng.bos.redhat.com systemd[1]: Starting Load CPU microcode update...
May 05 14:44:18 dell-per210-01.khw.lab.eng.bos.redhat.com systemd[1]: Started Load CPU microcode update.
~]#

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1851