From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1lOko5-0004u0-8V for mharc-grub-devel@gnu.org; Tue, 23 Mar 2021 13:27:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOko3-0004oG-Hs for grub-devel@gnu.org; Tue, 23 Mar 2021 13:27:03 -0400 Received: from dibed.net-space.pl ([84.10.22.86]:38647) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_3DES_EDE_CBC_SHA1:192) (Exim 4.90_1) (envelope-from ) id 1lOko1-0003zQ-44 for grub-devel@gnu.org; Tue, 23 Mar 2021 13:27:03 -0400 Received: from router-fw.i.net-space.pl ([192.168.52.1]:44002 "EHLO tomti.i.net-space.pl") by router-fw-old.i.net-space.pl with ESMTP id S1152233AbhCWR04 (ORCPT ); Tue, 23 Mar 2021 18:26:56 +0100 X-Comment: RFC 2476 MSA function at dibed.net-space.pl logged sender identity as: dkiper Date: Tue, 23 Mar 2021 18:26:53 +0100 From: Daniel Kiper To: Colin Watson Cc: Javier Martinez Canillas , Michael Chang , The development of GNU GRUB , Marco A Benatto Subject: Re: [PATCH v2] i386-pc: build verifiers API as module Message-ID: <20210323172653.xpte5rljcdyhi62k@tomti.i.net-space.pl> References: <20210318113026.24963-1-mchang@suse.com> <20210322152000.ebheegnkkhpqa4d3@tomti.i.net-space.pl> <20210323041621.GA4480@mercury> <000fc9a9-25cd-4d8c-5472-ac16358d888b@redhat.com> <20210323132715.GP26923@riva.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210323132715.GP26923@riva.ucam.org> User-Agent: NeoMutt/20170113 (1.7.2) Received-SPF: pass client-ip=84.10.22.86; envelope-from=dkiper@net-space.pl; helo=dibed.net-space.pl X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 17:27:03 -0000 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