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.