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

[Robbie Harwood]

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

signature.asc
Description: PGP signature