On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote: > On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > 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. You're painting with a very wide brush here. The concept of UKIs has been in development for a long time. [1] adds the initial implementation of sd-stub in systemd, and that commit is from 2015! Many, many people have been working on the details of the concept and vying to make the implementation better. That group includes most maintainers of systemd, but also external contributors. Accusing us of not interacting with "real users" is strange. [1] https://github.com/systemd/systemd/commit/0fa2cac4f0cdefaf1 > 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. I think that limiting this Change to VMs is a very smart move. It is a very clear case that we can actually tackle right now, and we generally know what concepts we need to cover it, and the code is either there or at least under significant development. Let's do this one thing right and learn from the experience. > 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. 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. > But again, we've eliminated the value of UKIs by doing so. > > 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. This is > *incredibly* common for RHEL administrators because there's a general > acceptance of proprietary kernel modules from vendors these days. Even > ignoring those, Red Hat's kernel feature support mindset is completely > incompatible with UKIs, because RHEL does default-off rather than > Fedora's default-on model for kernel features. We could debate until > the cows come home on whether it's right or wrong, but their current > mindset essentially means tons of common hardware becomes unsupported > quite regularly. The ELRepo project is popular among RHEL folks > because it restores those drivers and makes it possible to use RHEL on > those machines through a combination of driver disks and kernel module > packages. > > 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. > 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. Whether the kernel is installed as an UKI or as a separate kernel+initrd, doesn't change much for driver loading. In SecureBoot mode, the kernel will refuse to load any module that is not signed. But there is a big difference for userspace code: with a UKI, the early boot userspace code is also signed and the signature can be verified like with the kernel. (And once this code has been loaded, and we have normal userspace, we can do futher verifications on other code that is loaded later.) If additional modules need to be loaded from outside of the UKI, this is entirely doable. Systexts are one solution that is proposed, but it may not be even be the best fit in this case, because sysexts are designed to extend the initrd file system with additional code. They are a good solution when for example you want to add a bluetooth stack to the initrd, but overkill for the case of a module file. For modules, what we need is a way for the initrd code to access some additional storage and e.g. try to load all files matching a certain name pattern as modules. This isn't rocket science, and once we have that, we're back in similar situation as with a separate initrd (apart from the part where we check the signature of initrd code before starting it). Whether we should change the verification and requirements on (external) modules is an interesting question, but mostly orthogonal to the topic at hand. > 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. TPM measurements haven't been used much in the Linux world yet, primarily because doing anything with them is very hard. UKIs (when combined with a boot loader that supports this) actually make things significantly easier: - PCR values after boot become predictable and can be pre-calculated (see www.freedesktop.org/software/systemd/man/systemd-measure.html). - since PCR values are pre-calculated, PCR statements (policies) on them can be signed by the distro and attached to the UKI (see https://github.com/systemd/systemd/blob/main/src/ukify/ukify.py). - This means that you can bind TPM-protected secrets to the certificate used by the distro (instead of specific PCR values, which necessarilly change with each update). - This means that you can build policies for TPM-protected secrets bound to various aspects of the machine state. A typical example would be allowing password-less decryption of the root LUKS volume, iff you're runnning Fedora with an official kernel and initrd and unchanged kernel command line, and the machine hasn't yet transitioned from the initrd to the host system. Another use of TPM measurements is obviously remote attestation. I'm personally less interested in this, but for cloud computing it's apparently pretty important. This is all still a bit vague and underdeveloped. We are finally starting to have technological pieces in hand to play with this at the distro level. > I am not convinced that you are providing security or reliability with this > and the trade-offs are *terrible* for regular users. Dunno, you make it sound like this would have some big impact on users. But after all, this is essentially a proposal to have an additional initrd packaging method in one corner of the distro. The old packaging method is not going away. The way that the initrd is built is not changed. If it works for those users who try it — great. If not, they can immediately switch back to the existing approach. Zbyszek _______________________________________________ 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
