Fonts and theming and what to do in future with SB

Fonts and theming and what to do in future with SB

[Steve McIntyre]

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

Thoughts??

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

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

[Robbie Harwood]

[-- Attachment #1: Type: text/plain, Size: 3574 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

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

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

[Robbie Harwood]

[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]

Zhang Boyang <zhangboyang.id@gmail.com> writes:

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

My testing with Chris's patch and approach for unicode.pf2 (in Fedora)
adds just under a megabyte - presumably this is due to benefits from
xz-compressing it, minus overhead to add the modules required for
support to our builds.

Is your suggestion that we should officially remove support for other
fonts, then?

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

As you say, someone would have to implement this first :)  And if we were
to go this route, I think we'd want to do the same for background
images.

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

"Disable secureboot in order to do this" is not a position I ever want
to take.  In a forced tradeoff between features and security, some users
will opt for features.  (And it's easier to just disable secureboot than
roll out one's own signing, unfortunately.)  So my preference is to keep
feature parity between SB and non-SB, even if that means dropping
customizability.

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

I don't agree with making shim more complicated.

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

[Zhang Boyang]

Hi,

On 2022/12/1 00:08, Robbie Harwood wrote:
> Zhang Boyang <zhangboyang.id@gmail.com> writes:
> 
>> On 2022/11/30 02:35, Steve McIntyre wrote:
>>
>>> 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.
> 
> My testing with Chris's patch and approach for unicode.pf2 (in Fedora)
> adds just under a megabyte - presumably this is due to benefits from
> xz-compressing it, minus overhead to add the modules required for
> support to our builds.
> 
> Is your suggestion that we should officially remove support for other
> fonts, then?
> 
>> 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.
> 
> As you say, someone would have to implement this first :)  And if we were
> to go this route, I think we'd want to do the same for background
> images.
> 
>> 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.
> 
> "Disable secureboot in order to do this" is not a position I ever want
> to take.  In a forced tradeoff between features and security, some users
> will opt for features.  (And it's easier to just disable secureboot than
> roll out one's own signing, unfortunately.)  So my preference is to keep
> feature parity between SB and non-SB, even if that means dropping
> customizability.
> 
>>> 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.
> 
> I don't agree with making shim more complicated.
> 

Then I think the best solution would be: wrap font files into PE files. 
Therefore we can sign font files directly and verify them using "shim", 
and there is no need to use memdisks or something like that. If I 
understand correctly, user can also sign their own font files with MOK 
using existing tools and no special infrastructure need to be introduced.

I'm planning to implement a PE unwrapper using `grub_file_filters`. 
Using it we can wrap even more type of files into PE files, like ELF 
files. I will send a RFC patch in few days.

> Be well,
> --Robbie

Best Regards,
Zhang Boyang