Leslie Satenstein
Some end-user feedback.
I believe in the KISS approach (Keep It Simple Sxxxx).
I would consider /boot as a btrfs volume, and not a sub-volume, but why
bother?
For me, it being a btrfs partition is definitely not a priority or urgency, as
I use rsync for backup/restore of the ext4 partition.
For my desktop setup, I have several disks with independent btrfs
partitions.These are not sub-volumes, again, they are fully independent.
I manually add them to my /etc/fstab after I install the vanilla Fedora Linux
distribution
I make use of them as I independent volumes. They definitely are not
sub-volumes.
Some common sense.=================
Most user disks today are of size 500gigs or more.I do not concern myself with
1024 megs for /boot. I also reserve/use 500megs for /boot/efi
Better to spend energy on other things.
On Wednesday, May 10, 2023 at 11:12:20 a.m. EDT, Simo Sorce
<s...@redhat.com> wrote:
On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering <mzerq...@0pointer.de>
> wrote:
> >
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) 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).
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
