On Do, 22.12.22 10:43, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > > > 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. > > > > Shim trusts MS and the main distro cert, grub is trusted from there, > then the OS trusts those and anything else the admin adds. That's how > It should work. Trust chains are sensible as long as they're > extensible. Hmm, that chain is partly backwards? it's the firmware that has to trust the msft cert which trusts shim, which trusts the distro cert, which trusts grub and the kernel. The thing that comes first at boot must trust the next, otherwise we'd have to boot into untrusted stuff first, which really misses the point? not grokking what you are trying tosay? > > > 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. > > One company is one company. It's not a variety of people and users. > Scale means nothing if it's not distributed. Well, you said you have not "heard" of anyone doing UKI security on non-x86. Now you have. 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
