Logo customization option in Heads menu

[mkopec]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Some of our users like being able to replace the bootsplash with a custom image. Right now the easiest option is to just rebuild the firmware image.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Add an option to change the bootsplash.jpg file in CBFS with a file from USB storage

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Some users may prefer not to have the option, to eliminate a potential security vulnerability.

Additional context
Add any other context or screenshots about the feature request here.

Continued from Dasharo/dasharo-issues#707

[tlaurion]

@mkopec @macpijan: If I understand correctly, the desired function here would be for:

• Configuration menu to propose to load a voodoo corrected bootsplash image from usb in running rom (that is done automatically when building rom with coreboot. That would be a limitation : jpg needs to be compliant prior of injection, no way we add convert app from imagemagick into Heads)
• Heads flashing logic modified to check if current firmware contains specially cbfs flagged bootsplash file as user file (just like pubkey ring, trustdb and config.user: type 50) and if so, extract bootsplash from running rom, delete bootsplash from rom to flash, inject user bootsplash into firmware to be flashed when flashing with preserved user setting, flash temporary rom result (as of now).

Meaning

• Flashing without preserving setting would revert to default rom bootsplash present at build time (OEM should brand their firmware at build time with bootsplash anyway in fork).
• Flashing keeping user settings would take user tagged bootsplash present in cbfs from running rom, inject it in rom to be fashed after hash verification and flash user desired bootsplash,
• Preserving rom user settings could from a commit on always take bootsplash in rom into next rom
• We could check if bootsplash is different and ask user to choose to keep current bootsplash or rom to flash?

Something i'm not thinking about? Preferences? Desires?
@JonathonHall-Purism thoughts?

[JonathonHall-Purism]

The idea seems pretty reasonable to me. If coreboot's image format support was a bit more complete (eliminating the voodoo), this would be a pretty natural feature.

Unfortunately with the image support the way it is though, I don't think I would expose this feature in PureBoot. I think it'd be reasonable to provide this as a feature, but perhaps for now guarded with something like CONFIG_SUPPORT_USER_BOOTSPLASH so we don't all have to offer it. IMO, it is too easy to flash a bootsplash that does not work correctly right now, and I have concerns that a particularly bad JPEG might prevent the machine from booting, etc.

That would be a limitation : jpg needs to be compliant prior of injection, no way we add convert app from imagemagick into Heads)

This could be improved by supporting another image format in coreboot. At one time I did a PoC with an LZMA-compressed BMP image in SeaBIOS (since it already had BMP and LZMA, a format like PNG would be nicer but this was a PoC). If the image support was better this would seem like a fairly practical feature to me.

• Flashing keeping user settings would take user tagged bootsplash present in cbfs from running rom, inject it in rom to be fashed after hash verification and flash user desired bootsplash,

• Preserving rom user settings could from a commit on always take bootsplash in rom into next rom

• We could check if bootsplash is different and ask user to choose to keep current bootsplash or rom to flash?

Yes I would treat this exactly as any other user setting. There is an implementation detail that it's handled differently since it needs to be read by coreboot itself before invoking Heads, but that's all implementation. No need for specific prompts during flashing, we have "flash erasing settings" for a reason.

From OP:

Some users may prefer not to have the option, to eliminate a potential security vulnerability.

There's no security issue here as far as I see. You already have access to flash the BIOS region, so you could just as well alter the coreboot ramstage code.

If you're thinking of LogoFAIL for UEFI, the problem there was that UEFI firmwares loaded custom bootsplashes from disk (outside the firmware), and at very early point in the boot flow where the disk was not supposed to be trusted yet. coreboot measures CBFS files into the TPM when used, so altering the bootsplash would be evident in Heads just as altering ramstage would.