[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] i386-pc: build verifiers API as module
From: |
Daniel Kiper |
Subject: |
Re: [PATCH v2] i386-pc: build verifiers API as module |
Date: |
Tue, 23 Mar 2021 18:26:53 +0100 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Tue, Mar 23, 2021 at 01:27:15PM +0000, Colin Watson wrote:
> On Tue, Mar 23, 2021 at 12:37:20PM +0100, Javier Martinez Canillas wrote:
> > On 3/23/21 5:16 AM, Michael Chang wrote
> > > 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.
>
> We don't need to take this out of proportion, though: the actual
> workarounds being discussed here are not that complicated, and certainly
> *far* less complicated than some of the existing workarounds that exist
> only for i386-pc.
>
> > 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.
>
> This has been an issue in some form or another for as long as I've been
> working on GRUB. It's not clear to me why it's particularly urgent to
> break things now, when patches to make things work again exist and
This is not new thing. I was saying about dropping support for small MBR
gaps on various conferences for at least a year. Nobody complained up
until now...
> aren't of unreasonable complexity compared to the rest of GRUB. (To be
> clear, I would be perfectly happy to be told that particular details of
> some particular patch are problematic; it's the blanket refusal even for
> simple and innocuous patches that don't add complexity or in some cases
> might even remove complexity that I find unreasonable.)
I think I explained it in the other email...
> I agree that the size constraints can be difficult at times, but well,
> that's boot loaders for you; they're a constrained environment. After
> all, as I understand it, the entire system of a core GRUB image with
> loadable modules originally came into existence due to this kind of size
> constraint.
OK but I do not agree that ancient limitations have to hinder further
development...
> For those pointing to the documentation change as justification of
> unilaterally ignoring certain constraints, I'd say that the number of
> users who'll actually have seen that in advance of their systems being
> broken is likely to be a pretty good approximation to zero. I support
> the basic idea of the documentation change, but it needs a *much* longer
> deprecation cycle. Yes, that may be inconvenient for us as GRUB
> developers.
We are all aware about the issue for years. I was saying about dropping
support for small MBR gaps from upstream for a year. Do you think it is
short "deprecation cycle"?
> Zooming out a bit, it's in the interest of the whole free software
> ecosystem for security updates to be reliable and not break existing use
> cases. I don't think any of us want users to be any more hesitant about
> installing security updates than they already are: the world is
> generally better off if we can deploy security updates as quickly as
> possible.
>
> The argument I'm making here is, I think, the same sort of argument by
> which Torvalds famously has a very low tolerance for userspace
> regressions in the Linux kernel. The argument there runs something like
> this: perhaps userspace is being objectively unreasonable, but
> nevertheless, it exists in the real world and nobody is helped by having
> to solve n-dimensional simultaneous equations in order to work out
> whether they can install a given new kernel version. Maintaining an
> intolerance of regressions reduces the friction for installing updates.
Yes, but I think we have to hammer out better story than keeping small MBR
gaps alive for the end of the world...
Daniel
- Re: [PATCH v2] i386-pc: build verifiers API as module, (continued)
- Re: [PATCH v2] i386-pc: build verifiers API as module, Colin Watson, 2021/03/22
- Re: [PATCH v2] i386-pc: build verifiers API as module, Daniel Kiper, 2021/03/23
- Re: [PATCH v2] i386-pc: build verifiers API as module, Lennart Sorensen, 2021/03/23
- Re: [PATCH v2] i386-pc: build verifiers API as module, Michael Chang, 2021/03/24
- Re: [PATCH v2] i386-pc: build verifiers API as module, Daniel Kiper, 2021/03/26
- Re: [PATCH v2] i386-pc: build verifiers API as module, James Bottomley, 2021/03/22
Re: [PATCH v2] i386-pc: build verifiers API as module, Michael Chang, 2021/03/23
Re: [PATCH v2] i386-pc: build verifiers API as module, Daniel Kiper, 2021/03/23
Re: [PATCH v2] i386-pc: build verifiers API as module, Michael Chang, 2021/03/23
Re: [PATCH v2] i386-pc: build verifiers API as module, Daniel Kiper, 2021/03/26