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. > > > > I assert that the proposal has not yet met the bar to overcome those > > > > issues. > > > > > > If the "those issues" is supposed to be that you hit the size of the > > > mokutil cert store once, then I fail to see the relationship to > > > UKI/sysext. After all, the fedora signing keys for sysexts would be > > > built into the kernel and hence not be charged against NVRAM. And the > > > fedora UKI is signed with the same key as our current kernels, which > > > are also not charged against NVRAM but are built into fedora shim. And > > > the shim signature key is the msft key. > > > > > > Yeah, if you want to build your own UKIs + sysext, then you have to > > > use mokutil to enroll a cert, but it would be entirely sufficient to > > > enroll one for that, and sign UKIS, kmods, sysext with them. > > > > > > (or, maybe you actually hit the NVRAM size limits because you enrolled > > > hashes, not certs? if so, then maybe address that?) > > > > > > > I do not want to add more things to Fedora that *will* cause people to > > potentially brick their systems because they have to screw around with > > UEFI to be able to extend what they can use to boot their systems. > > Bricking systems is not an issue for VMs, where this proposal > is targetted. > > > 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. 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. 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
