> I guess that shows how unfamiliar I am with UEFI boot Fedora.
You would
> encrypt /boot to ensure that your boot images have not been tampered with, or
> config files haven't been read by somebody other than the end user.
>
Encryption != integrity/authentication. The only thing encryption
guarantees is that the data is not visible, not that it hasn't been
tampered with. Usually, dm-verity or dm-integrity is used for what
you're asking for. Android uses dm-verity, if I remember correctly.
Or measurement and attestation via TPM2.
> > sd-boot still wouldn't work out-of-the-box though, due
to /boot being
> > xfs not vfat and firmware typically not shipping with xfs drivers.
>
> If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used
> for /boot in Fedora, by default.
>
> > We could that by using vfat for /boot. Or by shipping & using xfs.efi,
> > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > filesystems.
>
> Is there a notable benefit to using that over GRUB2, which already has support
> on both UEFI and BIOS?
>
Less complexity in the boot chain, mainly. But the EFI drivers would
need to be signed by MS, I think? That would massively complicate
things.
I believe that to be correct, of could Apply has control over that for
their platform, you'd also need to load them some how, I'm guessing
sd-boot could try loading/locking if it can't read a file system...
suddenly things start to head towards complexity again.