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