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

[Robbie Harwood]

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.

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

Be well,
--Robbie

signature.asc
Description: PGP signature