> > 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. _______________________________________________ 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
