On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr <johnmh(a)splentity.com> 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.
> 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.
--
真実はいつも一つ!/ Always, there's only one truth!