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 <simo(a)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
<mzerqung(a)0pointer.de> wrote:
>
> On Di, 09.05.23 08:22, Neal Gompa (ngompa13(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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