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. > > > 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. 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
