[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Zhang Boyang
Subject: Re: Fonts and theming and what to do in future with SB
Date: Thu, 1 Dec 2022 16:30:09 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0


On 2022/12/1 00:08, Robbie Harwood wrote:
Zhang Boyang <> 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

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

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

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,

Best Regards,
Zhang Boyang

reply via email to

[Prev in Thread] Current Thread [Next in Thread]