Bug 1093213 - kernel+dracut: module firmware semantic gap
kernel+dracut: module firmware semantic gap
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P4 - Low : Enhancement (vote)
: ---
Assigned To: Luis Chamberlain
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-05-14 20:04 UTC by Luis Chamberlain
Modified: 2020-06-05 09:28 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
daniel: needinfo? (lurodriguez)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luis Chamberlain 2018-05-14 20:04:39 UTC
The MODULE_FIRMWARE() macro extends the modinfo for a module to add required firmware. This is used by dract on /usr/lib/dracut/dracut-init.sh to iterate over modules and for modules which it detects are installed on initramfs, it only complains if the firmware is not present on /lib/firmware.

for _fw in $(modinfo -k $kernel -F firmware $1 2>/dev/null); do

This is also the mechanism currently upstream on dracut. However MODULE_FIRMWARE() is not used for certain firmware files where the driver constructs the name at runtime dynamically. This could mean a failure for drivers which miss their firmware and don't have a reprobe trigger of some sort.

Many modules may simply fail if the firmware is not loaded early, as they have no reprobe. Unloading and loading can help but that is in no way user friendly.

Its unclear exactly which modules this could fail for at this point as there is no way to check for this.

This semantic gap was brought up recently in light of IMA's future possible use for relying on the modinfo set by MODULE_FIRMWARE() also for building the new future IMA firmware signing policies [0].

[0] http://lkml.kernel.org/r/20180514192853.GM27853@wotan.suse.de
Comment 1 Luis Chamberlain 2018-05-14 20:07:39 UTC
Setting as P4 low priority due to the lack of an annotation of a actual real world driver and since this is a general long term architecture objective.

Storage folks may have an ideal candidate driver in mind whereby the firmware name is constructed dynamically at run time and MODULE_FIRMWARE() is *not* used currently.
Comment 2 Daniel Molkentin 2020-05-29 16:29:43 UTC
Hey Luis. As I am revisiting stale open issues I came across this one. On our end, we are finally tracking the latest dracut version again, but even that one is limited to the abilities of libkmod (albeit directly now, rather than indirectly). But obviously this doesn't change much if we cannot reconstruct the firmware names from module metadata.

Has there been any progress on the kernel side in the meanwhile?
Comment 3 Daniel Molkentin 2020-06-05 09:28:07 UTC
Hey Luis, I have discussed this with the team and we agree we can support an augmented version of MODULE_FIRMWARE() that e.g. contains wildcards. However, we cannot make wild guesses. I am assigning this issue back to you. Once the kernel has the required changes, I am happy to implement support in dracut. I'll stay on the issue to remain in the loop.