RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1589987 - microcode_ctl "list" text file + dracut with hostonly disabled breaks early microcode loading
Summary: microcode_ctl "list" text file + dracut with hostonly disabled breaks early m...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: microcode_ctl
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Petr Oros
QA Contact: Rachel Sibley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-11 19:11 UTC by paulgraydon
Modified: 2018-10-30 09:48 UTC (History)
1 user (show)

Fixed In Version: microcode_ctl-2.1-33.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 09:45:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:3097 0 None None None 2018-10-30 09:48:04 UTC

Description paulgraydon 2018-06-11 19:11:47 UTC
Description of problem:

The microcode_ctl package picked up a list text file in /lib/firmware/intel-ucode.  Dracut, when hostonly is disabled, effectively cats that entire directory in to a single file, GenuineIntel.bin, which it then drops in the initramfs file ready for early loading by the
kernel.
The presence of a text file there causes the early loading to break, leaving it until later on in the booting process before the microcode is loaded.

When hostonly is left enabled (default mode) everything works fine, however that's not practical in my environment (I'm assuming other users may also have hostonly disabled and will be running in to this)

Version-Release number of selected component (if applicable):

microcode_ctl-2.1-29.2.el7_5

How reproducible:

Every time

Steps to Reproduce:
1. Find a system using BIOS/microcode old enough that the microcode packages have an update for it.  (I'm seeing this on a skylake based system)
2. Configure dracut to disable hostonly mode (note dracut has some surprising precedents behaviour over the config).
2. run 'dracut -f'
3. Reboot.  Look at the dmesg output.

Actual results:

start of kernel output:
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu

.. and later on confirmation of old microcode version still present ..
[   37.027044] microcode: CPU0 sig=0x50654, pf=0x80, revision=0x200003a

Then finally the microcode update happening at a later stage:
[  126.178762] microcode: CPU0 sig=0x50654, pf=0x80, revision=0x200003a
[  126.264963] microcode: CPU0 updated to revision 0x2000043, date = 2018-01-26

Expected results:

If you drop the /lib/firmware/intel-ucode/list file and re-run `sudo dracut -f`, early microcode works:

start of kernel output:
[    0.000000] microcode: microcode updated early to revision 0x2000043, date = 2018-01-26
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu

and confirmation later on confirmation:
[   37.183825] microcode: CPU0 sig=0x50654, pf=0x80, revision=0x2000043
[   37.259738] microcode: CPU1 sig=0x50654, pf=0x80, revision=0x2000043

Alternatively disabling hostonly also results in the same behaviour.

Additional info:

Not sure if you'd classify this as a dracut bug, a microcode_ctl bug, or if this is an issue on the kernel side.  I filed this against microcode_ctl because this is where the change causing the impact appears to have come from.

Comment 2 paulgraydon 2018-06-11 22:47:36 UTC
I was curious where this file came from.  It didn't look like something you'd just make & distribute.

I pulled the latest two microcode updates from:
https://downloadcenter.intel.com/download/27776/Linux-Processor-Microcode-Data-File

20180312 doesn't have it, 20180425 does.

From the release notes for 20180425:

-- intel-ucode/ --

intel-ucode directory contains binary microcode files named in
family-model-stepping pattern. The file is supported in most modern Linux
distributions. It's generally located in the /lib/firmware directory,
and can be updated through the microcode reload interface.


So there's probably at least a reasonable assumption that intel-ucode would only contain microcode, however Intel appear to have gone away from that position, even if the release notes don't explicitly call it out.

Comment 6 errata-xmlrpc 2018-10-30 09:45:55 UTC
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-2018:3097


Note You need to log in before you can comment on or make changes to this bug.