grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2] i386-pc: build verifiers API as module


From: Javier Martinez Canillas
Subject: Re: [PATCH v2] i386-pc: build verifiers API as module
Date: Tue, 23 Mar 2021 12:37:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0

On 3/23/21 5:16 AM, Michael Chang wrote

[snip]

> 
> Afterall, keeping existing running system to survive update (NOT new
> install) is really an important thing as many can't afford that to
> happen. If we can make it any better to reduce the cost please consider
> to do it. It doesn't conflict with the purpose to stop the short mbr gap
> support, given we all know the broken system can be avoided in the first
> place ...
>

My take on this is that we are conflating the need for distros to prevent an
update to break their users' existing installs, with a new GRUB release that
ships a set of CVE fixes (among other things).

I do agree that distros should avoid breaking users' installs, but don't think
that upstream should keep supporting the 63 sectors embedding are size forever
just to facilitate that. Otherwise it is a race to the bottom, since GRUB will
have to pile up workarounds and massage the code just to keep this constraint.

In the past, we posted other patches that we had been carrying for a long time
downstream (i.e: "kern: Make grub_error() more verbose" [0]) and were told it
couldn't be accepted due increasing the core.img size. It's really hard to add
new stuff by keeping this constraint, without having a lot of ifdefery in GRUB.

Also, most partitions tools have been aligning to a MiB boundary for quite some
time by now. So I don't believe is the correct trade-off for upstream to support
the 31 KiB embedding gap, in detriment of the 1 MiB case that's much more 
common.

Yes, it's a bummer to have to carry downstream patches (and we have a bunch in
our distro) just to support existing users. But it's up to each distro to decide
what's the proper action to take for their supported OS releases (e.g: rebase to
the latest 2.06 version with some patches, only backport security fixes, etc).

For this particular case, it might be better for distros to just revert commit
9e95f45ceee ("verifiers: Move verifiers API to kernel image") instead of making
it conditional for i386-pc, adding complexity to the GRUB upstream code IMO.

As mentioned, not every upstream change may work for all distros. For example,
we had to revert e346414725a ("templates: Disable the os-prober by default")
since otherwise users that don't have anything set in their /etc/default/grub
wouldn't have entries for other OS in their GRUB config file anymore.

[0]: 
https://lists.endsoftwarepatents.org/archive/html/grub-devel/2020-03/msg00053.html

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat




reply via email to

[Prev in Thread] Current Thread [Next in Thread]