On Monday, July 6, 2020 1:34:05 PM MST Neal Gompa wrote: > On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > wrote: > > > > > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot > > > and > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > files you can find there are public anyway, you can download them from > > > the fedora servers. Encrypting /boot would make the boot process more > > > fragile for no benefit. > > > > > > > > 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. That's true, in an ideal world, one of these modules would be used. However, LUKS is often sufficient to know that it hasn't been modified, depending on the ciphers used, if it does load correctly. > > > 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. It's less complex to maintain one solution for both types of boot, I'd imagine. I'm not the one that'd be doing the work to support it, so far be it from me to prevent somebody from doing so, but that's just what it sounds like. Right now, we have one solution that works well for both. -- John M. Harris, Jr. _______________________________________________ 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
