On Di, 20.12.22 11:28, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > 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 presume this is supposed to be a comment on systemd upstream, which includes me? Dunno, I think I have quite a good idea how people use systemd, and how general purpose distros like Fedora use it. Because I get the firehose of feedback on it. From *all* distros, and from all ways how peole use it. > 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. That's simply not true. Along with UKIs we developed the "sysext" concept, to make them extensible. Primary usecase: extend the basic initrd with drivers/subsystems that you want on some systems but not all. > For bare metal, we *need* these drivers in early boot, though. 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. In the UKI model the UEFI stub (i.e. systemd-stub) actually loads the sysext images from UEFI mode still, via UEFI fs APIs. i.e. they area already in memory when the initrd initializes, and can be used instantly. They are validated via verity/kernel certification keyring. > 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. > But again, we've eliminated the value of UKIs by doing so. I don't see any value being "eliminated". > 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. In the UKI model, there's no way to incorporate > early boot storage, network, and graphics drivers. There is, 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 authentication is tied to kernel keyring authentication actually, exactly like kernel modules. The kernel keyring can be populated via mokutil. > In other operating systems (notably Windows), Secure Boot certificates > are not used for blocking or enabling kernel-level drivers. Instead, > there's a kernel-level certificate store that is used to validate and > enable drivers, allowing everything to be managed in a hardware > platform agnostic way. I think people currently accept that mokutil is the certificate store for Linux. If you don't like that, I might even agree to some point with that, but this isn't new in the context of UKIs or sysext, we just use the very same infrastructure kmods use. > I've also yet to hear of a decent reason for > TPM measurements too. Block or filesystem verity provides similar > guarantees to provide tamper resistance and are both much easier to > debug than TPM interfaces. Unlocking secrets via TPM is usually what you want for write acccess. Verity is read-only only. > With my FESCo hat on, I'm uneasy about this change. With my "Fedora > user and advocate" hat on, I think that the UAPI group has failed to > provide something useful to the Linux world here and I would be > extremely apprehensive about Fedora adopting any portion of this > stuff. Umpfh. This is FUD. Please read up before writing scathing comments like that. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
