Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Di, 09.05.23 12:37, Neal Gompa (ngompa13@xxxxxxxxx) 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.

So you basically want to rebuild Fedora so that FDE is not available?

> We're generally looking toward encrypting subvolumes individually
> using the upcoming Btrfs native encryption capability rather than
> using LUKS. That allows us to

How do you establish trust in the underlying file system? The thing
that kernel fs maintainers made very clear is that they do not
consider Linux file systems safe regarding rogue offline
modification. Hence you must establish trust somehow *before* you
mount the fs, which pretty much means LUKS.

Linux fs maintainers also made very clear that they generally consider
alternative implementations of their file systems as unsupported, and
a problem. The big relevant Linux file systems consider only the
implementation in the Linux kernel as defining the format. Which means
that anything like an alternative implementation of btrfs or xfs or
ext4 in things like grub or EFI is expressly against the wishes of the
people who maintain the file systems.

Or in other words: what you are proposing appears like a very bad
idea, and in fact even upstream Grub wants to get away from
maintaining thei own fs drivers for Linux fs as I hear, because it's
so untenable to them, too.

Seriously, bury this idea.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux