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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
