On Thu, Dec 22, 2022 at 06:38:56AM -0500, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote: > > > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > > > > > > > On Di, 20.12.22 17:11, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > > > > > > > > > > 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. > > > > > > > > > > In fact, everyone I talk to seems to think it's basically impossible > > > > > because of how it works at the firmware level. > > > > > > > > > > It's telling that neither Windows nor macOS use Secure Boot like Linux > > > > > does. And they don't precisely for the reasons I outlined. > > > > > > > > Yes, Linux never solved the initrd hole so far, but that's not really > > > > the fault of SecureBoot, it's the fault of Linux if you so > > > > will. And this proposal is an attempt to finally do something about > > > > this, and get things in order to actually deliver what the other OSes > > > > all are delivering. > > > > > > > > I understand the big issue you have is that the certificate store for > > > > Linux (i.e. the mokutil db) is limited in size because EFI variable > > > > NVRAM is limited in size? If that's the big issue you are having then > > > > that's absolutely something the Linux community can fix, and can > > > > address. Specifically, shim could allow storing the cert store on > > > > disk, and authenticate it at boot via the TPM. Not trivial, but > > > > doable. And certainly not the firmware's fault... > > > > > > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if > > > > the way Linux/shim/mokutil implement the cert db is done the way it is > > > > currently done. > > > > > > > > > > Frankly, I'm aggravated by the increased reliance on UEFI features > > > without fixing Linux's problems with UEFI features. If we stopped > > > relying on UEFI for the cert store, a lot of my issues would go away, > > > because then we can design better workflows for managing certificates. > > > It makes automation possible, it makes management possible, and it > > > opens the doors to experiment with how to do layered images for boot > > > (e.g. UKIs + system extension images) without bricking people's > > > computers. > > > > So your objections are completely unrelated to the use of UKIs, > > and should not be a blocker for this feature proposal. You're > > just asking people to work on other UEFI related problems. > > > > It is not unreasonable to have to deal with it for VMs either. Having > custom drivers needed for workloads where hardware passthrough occurs > is not unusual. While you can kind of handwave graphics, I've seen > storage and network devices passed in too. The initrd in the UKI only needs to provide kmods needed for getting the rootfs up, once that's available all other kmods are available. It is reasonable to assume that any passthrough storage is not likely to be used for the VM rootfs, instead for data volumes. > > > Just because today it's only about VMs doesn't mean I can't figure out > > > you want to do more with it down the road. I want to see some > > > demonstration of someone actually caring about the user experience for > > > once with the boot stuff. > > > > If something is proposed for bare metal in the future, then raise > > the problems at that point. It is unreasonable to demand that we > > fix problems for a use case that is not in scope for what is being > > proposed. Anything related to bare metal was explicitly out of > > scope, precisely because it will massively increase the complexity > > of what needs to be addressed, making the task infeasible. We need > > an incremental path where we can tackle individual practical tasks > > rather than trying to solve everything in one go. > > > > Yeah, and what happens when it gets punted again when that happens? I > do not think it's unreasonable to bring these objections up front when > this is clearly marked as a "phase 1" Change that implies UKIs will be > used in more and more scenarios over time. The proposal gives an indication of what's expected > Also, just because *you* intend it for VMs doesn't mean that's what is > going to happen. Someone is going to do something to try to use that > UKI in a bare metal deployment, possibly by using sysexts or squashfs > or god forbid OCI images. Well people can do all this today, because they can use dracut to build a UKI and sign it with certs they're enrolled with shim. That doesn't imply that Fedora is on the hook to give them solutions to problems they may hit when doing this. > I have to think about what happens when the cat is out of the bag. > What I want is not necessarily a solution to this now, but a > commitment that someone will actively work on fixing these problems > *before* proposing the next phase and have it ready *before* making > any future proposals on UKIs. If you can't do that, I can't in good > faith consider incrementally supporting UKIs, because there's > effectively no plan to make them work as a future default way of > shipping the Linux kernel. No one can accurately predict what they'll have the time to work on in the future, especially if it is for a problem that is not impacting a supported usage scenario they're addressing. So while someone could make a committment, I wouldn't put any weight on it being followed up in any particular timeframe. If there is a future proposal for Fedora that actually targets the scenarios with problems identified, then you can reasonably expect someone to commit to addressing them & have confidence in them following through on the commitment, because it would be a core part of the Change proposed. 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
