[elrepo] kernel-lt and microcode updates

[Phil Perry]

On 19/06/2020 16:33, Orion Poplawski wrote:
> On 6/18/20 6:45 PM, Akemi Yagi wrote:
>> On Thu, Jun 18, 2020 at 9:33 AM Orion Poplawski <orion at nwra.com
>> <mailto:orion at nwra.com>> wrote:
>>
>>      Hello -
>>
>>      I was poking around and noticed some differences in microcode output in dmesg
>>      between the stock EL7 kernel and kernel-lt:
>>
>>      dmesg-3.10.0-1127.10.1.el7.x86_64:
>>      [    0.000000] microcode: microcode updated early to revision 0xd6, date =
>>      2019-10-03
>>      [    5.997673] microcode: sig=0x406e3, pf=0x80, revision=0xd6
>>      [    5.998518] microcode: Microcode Update Driver: v2.01
>>      <tigran at aivazian.fsnet.co.uk <mailto:tigran at aivazian.fsnet.co.uk>>, Peter
>>      Oruba
>>      [    0.000000] microcode: microcode updated early to revision 0xd6, date =
>>      2019-10-03
>>      [    6.035419] microcode: sig=0x406e3, pf=0x80, revision=0xd6
>>      [    6.035503] microcode: Microcode Update Driver: v2.01
>>      <tigran at aivazian.fsnet.co.uk <mailto:tigran at aivazian.fsnet.co.uk>>, Peter
>>      Oruba
>>      [   25.411983] microcode: updated to revision 0xdc, date = 2020-04-27
>>
>>      dmesg-4.4.227-1.el7.elrepo.x86_64:
>>      [    0.052043] SRBDS: Vulnerable: No microcode
>>      [    0.052066] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
>>      [    1.807176] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0xc6
>>      [    1.807189] microcode: CPU1 sig=0x406e3, pf=0x80, revision=0xc6
>>      [    1.807210] microcode: CPU2 sig=0x406e3, pf=0x80, revision=0xc6
>>      [    1.807230] microcode: CPU3 sig=0x406e3, pf=0x80, revision=0xc6
>>      [    1.807312] microcode: Microcode Update Driver: v2.01
>>      <tigran at aivazian.fsnet.co.uk <mailto:tigran at aivazian.fsnet.co.uk>>, Peter
>>      Oruba
>>
>>      This leads me to believe that the microcode is not getting updated when using
>>      the elrepo lt kernel.  Is that expected?
>>
>>      Thanks,
>>
>>         Orion
>>
>>
>> Looks like the explanation is in the posttrans scriptlet of microcode_ctl.
>>
>> rpm -q --scripts microcode_ctl
>>
>> [quote]
>> ...
>> # 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 kernel-debug kernel-rt kernel-rt-debug"
>> ...
>> [/quote]
>>
>> Therefore, initramfs will not be regenerated for kernel-ml or kernel-lt.
>>
>> By the way, the microcode file name as shown by the lsinitrd command is:
>>
>> kernel/x86/microcode/GenuineIntel.bin (Intel)
>>
>> or
>>
>> kernel/x86/microcode/AuthenticAMD.bin (AMD)
>>
>> Akemi
> 
> While this may be an issue when microcode_ctl updates come in, in this case
> I've just installed kernel-lt on a system so the initramfs images should be fresh.
> 

Agreed. Are you sure that kernel-lt was installed after microcode_ctl? 
You can always try reinstalling kernel-lt to test. Kernel-lt doesn't do 
anything special, so should incorporate the latest microcode into it's 
initramfs image.

The %triggerin fix for microcode_ctl updates has been finalised and 
tested [1], and we are confident it should fix the issue. It will be in 
the next releases of kernel-lt and kernel-ml for el7. We are currently 
testing on el8 and expect to roll out there too shortly for kernel-ml 
packages.

Phil

[1] https://elrepo.org/bugs/view.php?id=1012