Re: trying to understand how the /boot/loader symlink is supposed to work.

[Chris Murphy <lists colorremedies com>]

On Fri, Feb 2, 2018 at 7:13 AM, Colin Walters <walters verbum org> wrote:


> Anyways it's a big messy topic, and gets into again how the distribution
> is built.  I'm just describing what we sort of settled on, but it's
> by no means the *only* way one could do things.  If someone has better
> ideas, I'd love to discuss.  Particularly if someone has a design for how
> updates to the bootloader itself should work.  (Is anyone using e.g. UEFI+ostree
> actually updating the copy of grub.x64 or whatever on the ESP?)

How does the kernel end up on /boot? I'm not sure what the limiting
factor is for updating the EFI OSLoader in a similar fashion.

Case A, the EFI OSLoader is updated by overwriting the existing one,
which is pretty much how everyone else has been doing this for a long
time now including Windows and macOS.

Case B, each distro directory on /boot/efi/EFI has a sub directory 0
and 1, same as what's found on /boot, with the switch for which
directory's bootloader to use determined by NVRAM boot entry, which
also gives you a fallback bootloader (the old one would be set as 2nd
in the NVRAM boot order list).

Case C, simplify the contents of the ESP to eliminate all casual
changes. This could be done with some minor changes to shim and just
let it be that simple ESP only bootloader. And then stop persistently
mounting /boot/efi and stop writing bootloader configuration changes
there, which is a bad habit anyway;  and only do these routine updates
on a journaled or COW file system. The basic bootloader on the ESP
points/forwards to a fixed location on /boot to find the current GRUB
and its configuration, which can then be atomically updated (assuming
the file system is frozen or successfully umounts - seeing as again
grub2-mkconfig does not even sync let alone actually full update all
fs metadata on journaled file systems)



On Fri, Feb 2, 2018 at 11:14 AM, Colin Walters <walters verbum org> wrote:
> On Fri, Feb 2, 2018, at 9:32 AM, Daniel Drake wrote:
> > On Fri, Feb 2, 2018 at 10:13 AM, Colin Walters <walters verbum org> wrote:
> > > What at least for Fedora Atomic we settled on is a model where
> > > the bootloader and its data are installed *once*, and never updated again.
> >
> > I'm curious why you went with this model. Is it just because it's an
> > unsolved problem? What if the bootloader has a bug that needs to be
> > fixed, or a security issue?
>
> We just haven't crossed the issue yet honestly.

Sure it has.
https://bugzilla.redhat.com/show_bug.cgi?id=1293725

rpm -q reports a version that does not actually match the bootloader
being used. That is a real trust loss problem in versioning. Not only
am I told I have version X when I don't, I also have no
straightforward or build-in way of learning what version I really do
have.

It's also a regression compared to yum/dnf updates on UEFI. I don't
know why on BIOS an RPM post install script hasn't been running
grub2-install (obsolete on UEFI) to make sure the updated binaries are
actually installed and used; but that it hasn't been done doesn't mean
it couldn't be done, it's just a function of not really taking
bootloader bugs, security vulns, and their updates very seriously. IF
they were taken seriously, we wouldn't accept any of this but in
particular not the effective regression on UEFI. Windows and macOS
have always had mechanisms for doing bootloader updates.

The idea it's not a problem I think is definitely a case of blinders
on. Just looking at Fedora's changelog for shim and grub, there are
many minor bugs, there are some major bugs, and a handful of serious
"update now" level security bugs that have come up over the years. The
idea we'd have to compose new installation media, and then clean
install the OS to fix something like this is not at all convincing.


-- 
Chris Murphy