On Tue, Dec 20, 2022 at 02:29:22PM -0500, Neal Gompa wrote: > On Tue, Dec 20, 2022 at 2:02 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > 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. > > > > Yes, system extensions are one mechanism for making the initrd > > content more flexible when using UKIs. There would be one base > > layer definiing the 90% common case, and a number of add-ons > > that can cope with niche use cases. This avoids the core UKI > > having to be huge and ship with every possible feature present. > > > > This is something that might be considered at a later phase, > > but is not a priority. What's proposed in phase 1 is sufficient > > to cope with the cloud VM common case. While device passthrough > > may be common in some industries/domains usage, it is not the > > common case for cloud computing in general. > > > > > But again, we've eliminated the value of UKIs by doing so. > > > > That is not correct. There are a number of benefits of UKIs. > > > > The most critical is that the initrd content and cmdline is > > covered by the SecureBoot signature. This remains true even > > with system extensions, as such extensions would be signed > > too. They do not neccessarily need to be signed by the OS > > vendor, they could use a 3rd party SecureBoot signing key, > > or the users' own key. That is TBD and not something we're > > actively considering - its not even mentioned in phase 2/3 > > ideas in the change proposal. > > > > Secure Boot keys are flawed. There are many documented problems with > relying on Secure Boot keys in the real world. Redesign to not use > them, please. We're aiming to fix the flawed usage of Secure Boot in the Fedora / RHEL distros, so it becomes useful. Simply ignoring the problems and carrying on with our current approach is not sustainable. > > TPMs. These are a core technology foundation of the confidential > > virtual machine stack. On Azure today, if you request an Ubuntu > > confidential VM, Azure will pre-encrypt the root filesystem and > > seal the LUKS key against predicted TPM PCR values. It guarantees > > that the root disk can only be decrypted by the specific VM > > instance that is requested, when it is running in SecureBoot > > mode with the expected measurments on AMD SEV-SNP confidential > > hardware. The Ubuntu image in Azure already uses UKIs, and boots > > them directly from shim, with no bootloader involved. The usage > > of SecureBoot and TPMs is all transparent to the user, since all > > the integration is handled by the OS vendor on their behalf. > > > > Well, how is that relevant to Fedora? We don't have Azure images, and > Red Hat still blocks us from meaningfully existing in that ecosystem, > which is why we don't have official WSL images or Azure images. Users can upload their own images, and 3rd parties have uploaded public Fedora images too. It is still relevant, even if Fedora itself doesn't officially publish images. As mentioned in another part of this thread, we're also expecting to support the same technology with KVM, so this use of UKIS will benefit Fedora on a fully open source hypervisor platform. > > > 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. > > > > As mentioned above, UKIs have provided a means to close the > > SecureBoot hole with unsigned initrd content that has existed > > in more or less every mainstream Linux distro. That is a > > clearly useful outcome, regardless of whether Fedora is interested > > in any other aspect of what that UAPI groups is proposing. > > > > In proposing the UKI support for Fedora, we're not coming at this > > as representatives of the UAPI group or its vision. We're trying > > to solve the problem of having a fully verified secureboot chain > > for VMs with no unsigned content, and to be able to use this to > > support confidential VMs with disk encryption sealed to TPMs, as > > required by Azure today, and likely KVM in future. > > Yeah, I seriously doubt this. Linux's model for supporting > confidential computing is not user-friendly, so I expect low adoption > and resistance once the flaws become apparent to would-be users. What exists in Linux today is not be user friendly. We don't have to resign ourselves to stick with the status quo. It is entirely possible to build a solution that works, without the user needing to get involved in understanding confidential computing, secure boot or TPMs. The hypervisor vendor and the guest OS vendor take responsibility for understanding the hard bits. The user ends up merely ticking a box to say they want an encrypted confidential VM. If it ends up being not user-friendly then we've failed in our goals, and of course it is not our expectation to fail. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
