All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <dkiper@net-space.pl>
To: Michael Chang <mchang@suse.com>
Cc: grub-devel@gnu.org, Colin Watson <cjwatson@debian.org>,
	Glenn Washburn <development@efficientek.com>,
	Marco A Benatto <mbenatto@redhat.com>,
	Javier Martinez Canillas <javierm@redhat.com>
Subject: Re: [PATCH v2] i386-pc: build verifiers API as module
Date: Fri, 26 Mar 2021 18:01:01 +0100	[thread overview]
Message-ID: <20210326170101.bjup2bcu3trlyh6v@tomti.i.net-space.pl> (raw)
In-Reply-To: <20210324044452.GB4620@mercury>

On Wed, Mar 24, 2021 at 12:44:52PM +0800, Michael Chang via Grub-devel wrote:
> On Tue, Mar 23, 2021 at 05:33:12PM +0100, Daniel Kiper wrote:
> > On Mon, Mar 22, 2021 at 08:45:27PM +0000, Colin Watson wrote:
>
> [snip]
>
> > > rounds of security megapatches we've also seen that the amount of
> > > divergence between upstream and various distributions in
> > > security-critical code is in fact a serious problem that needs to be
> > > addressed, and so I'm not happy about adding more to it for things that
> > > touch e.g. the verifiers framework - obviously a security-critical
> > > component.
> > >
> > > However, we probably won't have any choice.  Bugs of the form "I
> > > couldn't upgrade without reinstalling my entire system" are quite likely
> > > to be considered critical by any distribution worth its salt, regardless
> >
> > How long are you going to support such systems? 1, 5 or 10 years? This
> > approach makes GRUB upstream as a hostage of small MBR gaps users.
> > Anyway, I think we have to make users aware that small MBR gaps are not
> > supported any longer. Otherwise we will be playing whack-a-mole game
> > which we will loose sooner or later.
>
> IMHO It is doing the right thing to declare MBR gap is not supported, it
> is also doing the right thing to not breaking updates. We are yet to
> seek out or arrive at right time to have short MBR gap completely out of
> the game. Maybe a few years later nobody would care as the legacy pc
> bios is diminishing, or at some point of time everyone here would agree
> that we really have to blow up the limit in order to move on and convey
> a clear message that people who is running short mbr gap won't receive
> grub updates any longer unless they change it - given we have give
> acceptable grace period for them to do the migration ...

After some thinking it seems to me we can do this. I can take "i386-pc:
build verifiers API as module", "kern/misc: Move grub_printf_fmt_check
to gfxmenu" and similar patches into 2.06. I will revert after the
release all the patches which adds ifdefery or make code ugly and do not
benefit other platforms than i386-pc. This way you will have support for
small MBR gaps in 2.06 and I will have clean code after 2.06 release.

Does it work for you guys?

Daniel


  reply	other threads:[~2021-03-26 17:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 11:30 [PATCH v2] i386-pc: build verifiers API as module Michael Chang
2021-03-22 15:20 ` Daniel Kiper
2021-03-22 16:16   ` Colin Watson
2021-03-22 20:09     ` Colin Watson
2021-03-22 20:19     ` Glenn Washburn
2021-03-22 20:45       ` Colin Watson
2021-03-23 16:33         ` Daniel Kiper
2021-03-23 17:45           ` Lennart Sorensen
2021-03-24  4:44           ` Michael Chang
2021-03-26 17:01             ` Daniel Kiper [this message]
2021-04-12 13:15               ` Daniel Kiper
2021-04-13  4:13                 ` Michael Chang
2021-04-14 13:22                   ` Daniel Kiper
2021-04-16 21:23                     ` Colin Watson
2021-04-20  3:49                     ` Michael Chang
2021-04-28 13:45                       ` Daniel Kiper
2021-03-22 21:43       ` James Bottomley
2021-03-23  4:16   ` Michael Chang
2021-03-23 11:37     ` Javier Martinez Canillas
2021-03-23 13:27       ` Colin Watson
2021-03-23 14:26         ` Javier Martinez Canillas
2021-03-23 17:26         ` Daniel Kiper
2021-03-23 16:48     ` Daniel Kiper
2021-03-24  3:50       ` Michael Chang
2021-03-26 17:22         ` Daniel Kiper
2021-08-22 19:50 Michael Schierl
2021-08-22 20:23 ` Didier Spaier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210326170101.bjup2bcu3trlyh6v@tomti.i.net-space.pl \
    --to=dkiper@net-space.pl \
    --cc=cjwatson@debian.org \
    --cc=development@efficientek.com \
    --cc=grub-devel@gnu.org \
    --cc=javierm@redhat.com \
    --cc=mbenatto@redhat.com \
    --cc=mchang@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.