Re: Fonts and theming and what to do in future with SB

[Michael Chang]

On Tue, Nov 29, 2022 at 03:24:51PM -0500, Robbie Harwood wrote:
> Steve McIntyre <steve@einval.com> writes:
> 
> > Hey folks!
> >
> > So, with the latest set of GRUB CVE patches we've fixed up a bunch of
> > potential crashes in font-handling code that could lead to Secure Boot
> > holes. These are good and useful fixes, and thanks to Zhang Boyang and
> > everyone else involved!
> >
> > There were also a few other changes:
> >
> >  * In SB mode, refuse to load fonts from outside of the signed GRUB
> >    image
> >  * Restrictions to image dimensions
> >  * Fix integer overflow in fbutil
> >
> > Locking down fonts here has caused some issues that I've seen.
> >
> > We didn't update the config generation code in util/grub.d, so we're
> > still generating grub.cfg files that will try (and fail!) to load
> > fonts from other locations at runtime in SB mode. This causes ugly
> > errors, and also causes GRUB to fail to set up video as normal. We can
> > fix this, but it would be nice to agree on something upstream rather
> > than as diverging distro patches.
> >
> > AFAIK Chris Coulson has a patch for the font loader to cause it to try
> > loading fonts from the embedded memdisk first. Is that the best
> > approach? If so, what fonts should we be embedding in the signed
> > image? It's a tradeoff between size and functionality, of course -
> > some people are happy with just "unicode" while others may want a
> > wider choice for added theming options. Is the size an issue for most
> > people?
> >
> > Or... Could/should we look at options to sign fonts separately? I've
> > heard suggestions to embed them into faked-up modules that we could
> > load with insmod, but of course we don't support signing modules yet
> > anyway... :-)
> 
> I personally don't like that we *pretend* we do have signed modules -
> that is, we pretend that `insmod` works when it doesn't.  (I am
> ambivalent on whether we should have signed standalone module support in
> general.)  So while I appreciate Chris's patch and am shipping it, I
> don't think faking `loadfont` too is a good longer-term solution.
> 
> I understood that these kinds of decisions have been made because it's
> easier than patching the config generation code.  I know we're getting
> into "boil the ocean" territory, but maybe there's work that could be
> done to improve that situation?  In general the feedback I've been
> getting on grub config is that it would be nice if we had less of it,
> for whatever that's worth.
> 
> It's also odd that we've elected to lock down fonts in this way but not
> images.  Perhaps this is a good opportunity to rethink how much
> customization we actually want to provide to distros and end users of
> our packages.  Concretely, it seems that we expose customization for
> three use cases:
> 
> 1. Distro branding.  A Debian or RHEL or what have you wants to make
>    their ISO perhaps say the distro name at the top and have a logo
>    background or something.
> 
> 2. Localization.  It is reasonable for users to want prompts and text on
>    the screen to appear in the language of their choice.
> 
> 3. Making it look cool / use the font I want / etc.
> 
> I think localization is resolved by bundling the unicode font, and it's
> a good idea to default to having that around.  Distro branding seems to
> me a limited use case - we can just bundle whatever we need for that
> into our signed images, if we want.  I'm less interested in any other
> customization: in RHEL and Fedora, we generally don't show a menu at
> all.  I would not personally be upset if we just removed most of the
> customizability - but I'm also not the target audience.

In SUSE/openSUSE we still keep up the tradition of using graphical
themed bootloader menu to *green* users as default, from grub/isolinux
gfxboot in the early days to the grub2 theme engine today. There are
also many of the users spending lots of their time as a hobby to make a
good looking theme and try to spreading their artwork. Removing the
customizability out of the source code and kill this feature will
certainly disappoint users who has been using grub for this long,
including me.

> 
> Thanks Steve for raising the issue on-list.  I'm curious what other
> distro vendors here think too.

I'm also advocated for a solution which is transparent to the generated
config so will pick up the patch from Chris. In that way probably we
could come up with a default directory in memdisk, say (memdisk)/font,
that grub will scan and load the fonts upfront during start up to
provide basic font support for default theme besides to external fonts.

Thanks,
Michael

> 
> Be well,
> --Robbie



> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel