On Do, 22.12.22 05:38, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > > 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. Well, the thing is: a chain of trust is a *chain*, hence you must ultimately hook validation to what the firmware provides you with as root. And that ultimately is the SecureBoot db on commodity hardware. If I buy a boring laptop at a store it will come with a UEFI cert store, and nothing else. Linux cannot really ignore that. If it did, then you'd not have a trusted boot chain, hence the whole excercsie would be pointless. > 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. As mentioned before: note that the Fedora signing keys are only built into shim and the kernel, not stored in NVRAM. But anyway, I think it would be great if shim could manage a cert store on disk, I already said that. But that's truly orthogonal to UKIs and sysext really. You keep trying to change topics away from UKI/sysext towards your general discontent with UEFI. > 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. Well, "foolish", eyh? The thing is that chain of trust works quite differently on each such system (if it exists at all). UEFI is a standardizing and unifying force that simplifies things greatly, since while not universal it's still the most widely adopted mechanism (and one of the more advanced). Generally, I am very sure we should focus on making the more limited stuff work like the modern stuff, and not the other way round. For example, there has already been work on making UKIs boot on grub/MBR, as mentioned, which is exactly how I think it should be done: move the old/legacy/simple stuff work more like the new/modern/featureful/standardized stuff, rather than the other way round. > 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. I work for a company that is working on ARM UEFI systems booting UKIs in massive scale. 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
