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

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

 



On Wed, May 10, 2023 at 12:00:36PM -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.

The firmware will start by booting a binary found in the ESP,
and thus given the ESP is untrusted (hostile) we need a means
to validate that binary's integrity no matter what, most likely
using SecureBoot & TPM PCR measurements. Using this mechanism
for validating the UKI makes sense since it has to exist no
matter what. There's no need for the filesystem to be authenticated
/ tamper resistant if the binaries themselves are authenticated
and tamper resistant.

> 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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
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