Hi, > > 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. Well, UEFI *not* defining some standard way to enroll user certificates actually is part of the problem. It is one of reasons why shim+mokutil exist in the first place. > 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. Ignoring the UEFI cert store is just not possible, that is the only one available and used initially. For booting the bootloader to have to work with the capabilities provided by the firmware. Doing something simliar for ppc would likewise depend on ppc-specific firmware features. Once shim is loaded both uefi and shim cert stores are available. Once the kernel is loaded that expands to uefi + shim + kernel. > 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. system extensions are verified after the kernel is loaded, so you are not limited to the uefi/shim cert stores for them. > 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. Yep. Because it's a standard. Having u-boot (assuming this is what you are referring to) provide standard UEFI protocols, then use standard efi boot process is much less work because there is only one piece in the boot process which needs to know the hardware specifics. Which is u-boot (playing the firmware role on many SBCs). > 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) Any aarch64 server I boot in some cloud is UEFI. aarch64 virtual machines use UEFI. UEFI implementations exist for RPI 3+4. > and RISC-V is not a UEFI platform either. https://github.com/tianocore/edk2-platforms/tree/master/Platform/RISC-V/PlatformPkg > 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. Booting UKIs in BIOS mode works with a patched grub (needed for hybrid bios/uefi cloud images). Of course that doesn't improve security because the bios lacks the features needed for that. You can still get the other advantages UKIs have like a more robust kernel update process. ppc uses grub too, so being able to boot UKIs on ppc too should be doable without too much effort when the platform maintainers think it is useful. > > 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. Because today fedora doesn't use sysexts and doesn't provide much tooling. Ideally the packages which drop some dracut module to /usr/lib/dracut/modules.d/ today will also drop a sysext to the correct place in the future. No manual steps needed. Users don't even need to know how this works under the hood. take care, Gerd _______________________________________________ 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
