On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering <mzerq...@0pointer.de> wrote: > > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) 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. That also has the side effect of us having half a chance of being able to port this security capability to non-UEFI platforms where we use fake UEFI implementations to bootstrap our boot process, because the amount of coverage required for fake UEFI implementations is considerably lower now. More generally, relying on UEFI-specific security features when most platforms are not being brought up with UEFI is foolish. ARM is almost entirely non-UEFI (except the tiny proportion of servers that almost no one has) and RISC-V is not a UEFI platform either. POWER uses OpenFirmware instead of UEFI, and IBM Z does something else entirely different. You *need* to think about these problems when designing this stuff. You can't take a myopic x86-only view to this. I have not heard of anything about UKI security for non-x86 because it seems to all be tied up in UEFI stuff. Coming back to "my issue", I've had this problem for six years, and for most of it "the Linux community" (specifically the Linux boot community) has brushed me off saying my issue doesn't matter. Even if it leads to bricked systems. Even if it makes it hard for people to use their computers. Even if it leads to people turning off Secure Boot. And finally, even if it means people don't use Linux at all because they can't make it work. > > > 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. > Maybe. It's not super intuitive from where I'm standing, and I know how all this stuff works. > > 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. 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
