On Wed, 2023-05-10 at 12:00 -0400, Neal Gompa wrote: > On Wed, May 10, 2023 at 11:12 AM Simo Sorce <simo@xxxxxxxxxx> wrote: > > > > On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote: > > > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > > > > > > > On Di, 09.05.23 08:22, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > > > > > > > > > I've been asked to consider converting /boot to a Btrfs subvolume so > > > > > that it no longer has a fixed space allocation to deal with the ever > > > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is > > > > > currently incompatible with how systemd views the world, because the > > > > > "discoverable partition spec" is wired to partitions, and there is no > > > > > equivalent spec for subvolumes of a volume. And I imagine that > > > > > XBOOTLDR (whatever that is) also would have a problem with this. > > > > > > > > This makese no sense. If you want /boot to just be a subvolume of the > > > > rootfs btrfs, then this would imply it's also covered by the same > > > > security choices, i.e. encryption. We want to bind that sooner or > > > > later to things like TPM2, FIDO2, PKCS11. And that's simply not > > > > feasible from a boot loader environment. > > > > > > > > Hence, the place the kernel is loaded from (regardless if you call it > > > > /efi or /boot or /boot/efi, and regardless what fs it is) must be > > > > accessible from the boot loader easily, without requiring > > > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. > > > > > > > > Hence: btrfs subvols won't work for this > > > > > > If we're not using LUKS for encryption, then this is not a problem. > > > We're generally looking toward encrypting subvolumes individually > > > using the upcoming Btrfs native encryption capability rather than > > > using LUKS. That allows us to > > > > > > 1. Pick which subvolumes are encrypted > > > 2. Pick the security binding method per subvolume > > > > > > For example, the root and home subvolumes would use TPM or some other > > > non-interactive binding. The user subvolume in home would decrypt with > > > user login. > > > > Neal, > > I think you are barking up the wrong tree here. > > > > The design of the boot loader *nedds* to be simple. > > > > Simple means, VFAT and *no trust* in the filesystem, individual files > > are signed and verified. > > Only the bare minimum *necessary* is in the boot partition, which means > > kernel images and the bare minimum init image needed to unlock and > > mount the root partition. > > > > There is no point in building a more complex system than that and load > > tons of garbage drivers in the EFI. > > > > Booting is a staged system, and should be kept as simple as possible to > > avoid duplication (which means subtle bugs and a ton of maintenance > > overhead). > > > > This proposal isn't better. Neither Windows nor macOS put critical > operating system code in the ESP, and we shouldn't either. But you > want to put kernels in the ESP? That's the wrong approach too. > > As soon as you throw UKIs in the mix, you've completely broken that > because now the absolutely most valuable code for your system is in a > "hostile" environment. At least we can make /boot authenticated and > tamper resistant as a Btrfs subvolume. Sorry but this really doesn't compute. Either you can verify signatures and then it doesn't matter that someone can tamper with the file system, or you can't and then you always have evil maid approaches to replace grub with malicious code anyway. There is no added safety or unsafety about any of these schemes. > I would rather have a multi-stage boot process, where the first stage > does just enough to unlock and load the OS volume to load the real > boot environment. I do not see any advantage, loading a kernel is what the first stage should do, then the kernel+initimage can do everything you need. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
