Hi, > I think UKIs are fundamentally flawed and are an idea that came out of > a group that doesn't really interact with real users enough to > understand how much of a problem they actually are. I realize that > this Change is only about VMs, but since it explicitly talks about it > being "phase 1", the implication is that future Changes are coming to > switch fully over. Consequently, I'm going to provide much more > holistic feedback instead of just nitpicking on this case.
That is correct, although I expect we'll support both ukis and traditional initrds in parallel for quite a while and the day where all use cases can be handled with ukis is far away. Too many use cases depend on todays host-generated initrd workflow. > In the Fedora case, things are simpler right up until we hit graphics > drivers. This is also a problem for VMs too, because GPU passthrough > is a common case for scientific and gaming workloads. As long as the > NVIDIA driver remains dominant in Linux, UKIs cannot work because by > design you cannot load anything that isn't part of the kernel image. > For bare metal, we *need* these drivers in early boot, though. No. The graphics drivers don't need be part of the initrd. Booting on vgacon or efifb until the root filesystem is mounted and drivers can be loaded from there works just fine. > And that's another problem: no third-party early boot drivers. Even if > you solve the signing issue, you need to introduce some kind of > two-stage OS boot process so we can bring up the bare minimum to load > a second image containing all the remaining drivers. And at that > point, you've defeated the purpose of UKIs. I've heard from some > people that system extensions (sysexts) would be a way to solve this, > and maybe it is. Yes, that problem is not solved yet. And, yes, sysexts are the IMHO most promising option to handle that. I suspect using them requires putting dracut upside down or replace dracut with something else, so I expect that will take a while to sort out (disclaimer: I don't have much insight into the inner workings of dracut). > But again, we've eliminated the value of UKIs by doing so. No. sysexts can be signed. > Speaking more broadly, there are also problems that will be introduced > as this trickles down from Fedora into prominent downstreams (assuming > this is accepted). In the RHEL case, you've basically broken driver > disks completely. Hmm? A driver disk could provide a sysext ... > The crux of the problem here is *signing*. All of this is tied up in > Secure Boot and TPM, which is the wrong place to actually handle this. sysext signatures are independent from secure boot. take care, Gerd _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
