On Tue, Dec 20, 2022 at 05:11:57PM -0500, Neal Gompa wrote: > On Tue, Dec 20, 2022, 4:27 PM Simo Sorce <simo@xxxxxxxxxx> wrote: > > > On Tue, 2022-12-20 at 14:29 -0500, Neal Gompa wrote: > > > 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. > > > > > > > Neal, you are being unnecessarily negative. And user-friendliness is > > directly related to the fact we do not have good support for it. This > > proposal would make SecureBoot fundamentally transparent, and if you > > don't see it and it works, I see no resistance happening. > > > > SecureBoot may not be to your liking but is what is installed on 99% of > > modern hardware sold, so it is a good idea to first show you can > > support it. Then if you have interested you can propose "something > > better". > > > > We have supported Secure Boot for over a decade now. In that timeframe, > literally nobody did anything to make all the workflows you talk about > easier and friendlier. What's done/not done in the past should not constrain us from trying to improve the future. > In fact, everyone I talk to seems to think it's basically impossible > because of how it works at the firmware level. That is a challenge at bare metal, but with virtualization many of the problems can be addressed. We should not in fact even need to rely on Microsoft signing certs for virtualization. It is possible to pre-enroll the certs associated with the guest OS the user intends to boot. In fact it is desirable todo this, since it gives the VM much greater protection if it only trusts the guest OS vendor certs. > Finally, unless this proposal harms Fedora I do not see why oppose it. > > If, as you fear, it won't work ... then it won't and we'll try > > something else. However, having some knowledge of the (security side of > > the) matter I do not see why it wouldn't work, once all the pieces fall > > in place. > > > > This adds significant complexity to the Fedora kernel package and it > effectively increases what we need to test for virtualized Fedora Linux > environments. The complexity to the kernel pacakge is negligible and has been presented to the kernel maintainers already and not had any unsolvable concerns raised in response. There is an increase in testing matrix, but this path is chosen primarily to ensure we can limit the burden long term. What we don't want is to end up in a situation where confidential VMs use a completely different OS setup / integration to normal VMs, which would entail shipping many extra cloud disk images. The approach we're taking aims to make it possible to have a single cloud disk image cover all virtualization deployment scenarios, legacy BIOS, UEFI (with SB+TPM), and UEFI with confidential VMs to minimize the burden of what we deliver for cloud. 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
