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

[Zhang Boyang]

Hi,

On 2022/11/30 02:35, Steve McIntyre wrote:
> 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?

Personally I prefer to embed Unifont to GRUB. This can be done by 
memdisk, or embed as code directly (like ASCII chars). For Unifont, this 
will make GRUB about 2.5MB (+150%) fatter. This is sufficient for vast 
majority of GRUB usecases.

It's also possible to embed only hashes of font files into GRUB 
(although not implemented yet). Therefore, distros can pre-generate a 
series of fonts files and add their hashes to GRUB bundle. End-users can 
choose their font in the pre-defined list from distros.

For those who want to use fonts which not in the pre-defined list. The 
last option would be disable secureboot or use MOK to sign their own 
GRUB bundle.

> 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... :-)

It seems "shim" can process PE files only, so it's hard to implement 
signature checking for other files (modules, fonts, etc.). A tradeoff 
solution is to wrap PF2 font into a PE file, so they can be processed by 
shim. A better solution would be add more functionality to "shim" to 
allow it process more types of files.

> Thoughts??

Best Regards,
Zhang Boyang