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. > > 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. Nah. UKIs + sysext are ultimately something that is simpler and much better to test than the current mess. Yeah, for a while we'll have to add complexity because to mechanisms will have to be supported, but eventually things are going to be simple and easier to test. > 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?) Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
