[elrepo] kernel-lt and microcode updates
Orion Poplawski
orion at nwra.com
Wed Jul 1 12:49:55 EDT 2020
On 7/1/20 10:21 AM, elrepo at lists.elrepo.org wrote:
> On 6/30/20 4:11 PM, Phil Perry wrote:
>> 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
>
> I just re-installed kernel-lt on my laptop:
>
> # grep -i microcode dmesg-3.10.0-1127.13.1.el7.x86_64
> [ 0.000000] microcode: microcode updated early to revision 0xd6, date
> = 2020-04-27
> [ 0.021352] SRBDS: Mitigation: Microcode
> [ 1.542686] microcode: sig=0x806ea, pf=0x80, revision=0xd6
> [ 1.542918] microcode: Microcode Update Driver: v2.01
> <tigran at aivazian.fsnet.co.uk>, Peter Oruba
>
> # grep -i microcode dmesg-4.4.228-2.el7.elrepo.x86_64
> [ 0.035312] SRBDS: Vulnerable: No microcode
> [ 0.992458] microcode: CPU0 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992471] microcode: CPU1 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992491] microcode: CPU2 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992511] microcode: CPU3 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992530] microcode: CPU4 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992550] microcode: CPU5 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992569] microcode: CPU6 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992588] microcode: CPU7 sig=0x806ea, pf=0x80, revision=0xb4
> [ 0.992673] microcode: Microcode Update Driver: v2.01
> <tigran at aivazian.fsnet.co.uk>, Peter Oruba
>
> and /proc/cpuinfo indicates that microcode is not updated
>
> Orion
turning on dracut logging it apprears that:
I: microcode_ctl: kernel version "4.4.228-2.el7.elrepo.x86_64"
failed early load check for "intel", skipping
I: *** Generating early-microcode cpio image contents ***
I: *** No early-microcode cpio image needed ***
that check is done in /usr/libexec/microcode_ctl/check_caveats
that is for early loading. not sure why the microcode.service also
seems to fail to load the firmware.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion at nwra.com
Boulder, CO 80301 https://www.nwra.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20200701/c1ee2b1d/attachment.p7s>
More information about the elrepo
mailing list