On Mon, Jul 6, 2020 at 5:05 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > 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. > It's not guaranteed though, and you shouldn't rely on that for verifying integrity if you care about that. You either will want an authenticated filesystem or use a dm stack configuration that includes authentication. > > > > 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. > If we wanted to be UEFI first, we could make BIOS boots emulate UEFI and boot through the UEFI chain all the way through. We already do this for some boards on ARM with U-Boot, if I remember correctly. If that were possible on x86, then we could get down to one boot chain path regardless. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
