Punting GPU Drivers From The Initramfs Due To Ever Increasing Firmware Bloat

[oiaohm]

That's a shame. I'm sorry to hear that. At least the flowchart improved your knowledge.

Are you any better at doing backups now? I know I'm not as diligent as I should be.

Do note I said drives. Yes it was backed up onsite with a offsite copy. But sods law won that round. Recovered lots of things but that file even cross matching the non damaged bits was not coming back. I got a 98% data recovery from that mess. Few very nice things I had made were lost for good.

Sometimes being diligent does not work out but 98% of my data was way better than zero. Of course I have not had the time to go though the complete UEFI specification again and make another one.

I have never calculated the odds of this 15 drives successfully all failed inside 40 mins while having zero reported smart issue and they were not all the same age or vendor and they were in 2 different locations. I do hope that was a once in a life time thing.

[ssokolow]

I have never calculated the odds of this 15 drives successfully all failed inside 40 mins while having zero reported smart issue and they were not all the same age or vendor and they were in 2 different locations. I do hope that was a once in a life time thing.

That's why I have a history of also getting copies onto dvdisaster-augmented DVD+R (preparing for a move to BD-R now) as soon as I can afford to, and sending irreplaceable creations that change too often for that to private repos somewhere like GitHub, BitBucket, MEGA, etc.

Make one of your media something where the drive mechanics/electronics are user-swappable whenever feasible, and, when not feasible, try to put someone else's efforts at redundancy behind one of the entries in your redundancy plan.

[chithanh]

I'm not sure what you had in mind, but we have versioning in the firmware used by amdgpu. The firmwares have standardized headers that the driver can parse to get version information, etc. The idea is that the firmwares should always be compatible so a particular firmware always has the same name. You can drop in replace an older firmware with a newer one. That saves space because you don't have multiple versions with different file names and you can easily roll out newer firmware to older kernels. On the off chance a firmware does end up having non-backwards compatible changes, we have added new files with a different name to handle that case, but it's only happened a couple of times.

I should have clarified. The firmware has version headers etc. but what is desired and lacking from radeon/amdgpu firmware is the exact firmware version indicated in the filename like Intel and now also NVidia do.
There were multiple instances where certain firmware versions were incompatible with certain kernel versions due to bugs or not properly implemented interfaces, we have multiple user reports of that. And it does make the life of distro packagers like me harder, especially when the LTS kernel does not work with the latest linux-firmware tree, but we need to update linux-firmware package because elsewhere in linux-firmware there were security bugs fixed.

Its not a 100 percent solved problem. Secure boot rules by Microsoft are changing over time. Mote you said signing kernel models/drivers to allow a third party bit to load. Rebuilding a kernel on install as the person was suggesting is not inside the current rules.

It is indeed not 100% solved, even for Microsoft. In fact there is a major UEFI signing key update pending because Microsoft's original secure boot keys (Microsoft Windows Production CA 2011 etc.) are set to expire in 2026, and have to be replaced with new keys.
Conveniently, Windows 10 is EOL in 2025, and I suspect this had to do with it so Microsoft doesn't have to deal with the fallout on older systems where the secure boot keys update might fail and that thus can no longer receive bootloader updates. Same for Apple T2 systems, where Apple would need to update the trusted certificates.

But that is not what I meant. Rather: To the extent that secure boot is solved on Linux, it usually includes the solution to getting 3rd party kernel modules signed.

Oh really? Show me a kernel with zero device drivers for your storage device accessing this "information" and reading a file from said disk. UEFI did read it after all, so why shouldn't Linux be able to, huh?

When I said the kernel doesn't know I meant without looking it up via its device drivers. Of course it's passed the UUID for instance. But the thing is it needs device drivers and filesystem drivers and a lot of other stuff to access it. Basically, what we're trying to avoid. Things that are put in an initramfs.

UEFI can access your USB keyboard/mouse totally fine in the BIOS or POST menu, systemd-boot can (using UEFI). So, why the fuck Linux can't? Linux cannot without having USB-HID drivers, either integrated into the kernel or loaded from initramfs. This is the issue (same with graphics). And yes, I have experience with this. I fucking tried it several times. And I build my own custom initramfs with custom scripts and experiment a lot.

This is not what I claimed. What I said is the information where the boot partition is located is available with not more than the standard firmware functions. Storage drivers can be built into the kernel and most do not need firmware.

What you ask for is also possible in two situations, but practicality is limited. One is when the Linux kernel is built with the UEFI stub, the call to ExitBootServices() can be postponed and everything including keyboard and storage remains accessible from within the kernel.
The other is using something like SVBUS to provide a VHD during boot, with only a generic driver required in the kernel.

I understand that OEMs like HP who ship FreeDOS preinstalled on modern systems without CSM use something similar to these methods. FreeDOS does not really have drivers for storage (except CD-ROM) nor USB input devices.

The practicality is limited by UEFI firmware calls being synchronous and single-threaded so not suited for modern operating systems. But for booting it might be sufficient.

[agd5f]

I should have clarified. The firmware has version headers etc. but what is desired and lacking from radeon/amdgpu firmware is the exact firmware version indicated in the filename like Intel and now also NVidia do.
There were multiple instances where certain firmware versions were incompatible with certain kernel versions due to bugs or not properly implemented interfaces, we have multiple user reports of that. And it does make the life of distro packagers like me harder, especially when the LTS kernel does not work with the latest linux-firmware tree, but we need to update linux-firmware package because elsewhere in linux-firmware there were security bugs fixed.

You are just trading one set of problems for another. If you have the version in the file name, then you end up with a proliferation of firmware files that you need to ship and you basically can only use the latest firmware with the latest driver.

[chithanh]

If you have the version in the file name, then you end up with a proliferation of firmware files that you need to ship and you basically can only use the latest firmware with the latest driver.

That is not how it works for Intel Wifi firmware. The driver can load a predefined range of firmware version numbers. Once there are incompatible changes (like changes that expose driver bugs or an ABI break) then a new version number outside the range is chosen. Only the last file in each range needs to remain in the linux-firmware tree.

[agd5f]

That is not how it works for Intel Wifi firmware. The driver can load a predefined range of firmware version numbers. Once there are incompatible changes (like changes that expose driver bugs or an ABI break) then a new version number outside the range is chosen. Only the last file in each range needs to remain in the linux-firmware tree.

Even with that scheme you can still run into compatibility issues. It's not really any different than using the same name for the file. It is effectively what amdgpu does when we run into a known incompatible FW change (change the file name). The combinatorics of testing every firmware with every kernel is the limiting factor.

[Old Grouch]

It is indeed not 100% solved, even for Microsoft. In fact there is a major UEFI signing key update pending because Microsoft's original secure boot keys (Microsoft Windows Production CA 2011 etc.) are set to expire in 2026, and have to be replaced with new keys.
Conveniently, Windows 10 is EOL in 2025, and I suspect this had to do with it so Microsoft doesn't have to deal with the fallout on older systems where the secure boot keys update might fail and that thus can no longer receive bootloader updates. Same for Apple T2 systems, where Apple would need to update the trusted certificates.

And this is why the current certificate-based security infrastructure is not fit-for-purpose. This is built-in obsolescence, which will generate vast amounts of (e-)waste.

There is a tension between wanting certificates that last as long as possible (to obviate the generation of e-waste) and needing to be able to expire certificates that are no longer trusted for some reason, Certificate Revocation Lists (CRLs) and associated processes do not work very well at all.

[oiaohm]

I understand that OEMs like HP who ship FreeDOS preinstalled on modern systems without CSM use something similar to these methods. FreeDOS does not really have drivers for storage (except CD-ROM) nor USB input devices.

https://www.freedos.org/download/

Not how they are doing it chithanh. Freedos does not work without a BIOS/CSM. Of course this does not prevent a CSM being a EFI signed bootloader. Yes a few OEMS you find seabios built as a EFI bootloader named freedos of course.. So just CSM outside the main firmware.

Of course a few OEM also ship systems with freedos on the harddrive that do not boot at all because the bios does not support CSM and they did not include a bootloader work around. Yes HP for you on many models.

Basically if freeDos is running on a UEFI system and that motherboard does not have CSM in the motherboard firmware you next question is where have they hid the CSM because you need to back up that file in-case you lose the harddrive. Yes it will be a vendor signed file so you cannot just substitute it and worse you can have 2 so call machines the same and that file is signed with different keys.

[Weasel]

This is not what I claimed. What I said is the information where the boot partition is located is available with not more than the standard firmware functions. Storage drivers can be built into the kernel and most do not need firmware.

The point is that they're not built into the kernel by default because there's too many and that's bloat for no reason; the user could boot from any one of them, or USB even. Loading it on demand (as a module) is better, hence in initramfs. You also need HID and graphics drivers at the very least.

Obviously you can configure your kernel to have them included in it. That's not good for generic kernel, or one that you expect to use on different machines in case of emergency.

[chithanh]

Loading it on demand (as a module) is better, hence in initramfs. You also need HID and graphics drivers at the very least.

But not necessarily the GPU firmware in initramfs.