Cannot set custom bootsplash in firmware via DCU nor cbfstool

[filipleple]

Device

VP2420

Dasharo version

v1.2.0

Affected component(s) or functionality

Setting custom bootsplash

Brief summary

After modifying the bootsplash region (even when trying to use the original file, or files known to work on other machines), bootsplash image no longer appears on boot and /sys/firmware/acpi/bgrt/image is no longer generated.

A 16:9 monitor is plugged in via HDMI and working.

How reproducible

100%

How to reproduce

See full log below

Expected behavior

The new bootsplash should be displayed, and the hash of /sys/firmware/acpi/bgrt/image should be identical to the image used.

Actual behavior

No bootsplash, no /sys/firmware/acpi/bgrt/image file

Screenshots

via dcu

ubuntu@3mdeb:~/dcu$ ./dcu logo read.rom -l img.bmp
Setting img.bmp as custom logo
Success
ubuntu@3mdeb:~/dcu$ file img.bmp
img.bmp: PC bitmap, Windows 3.x format, 1024 x 768 x 24, image size 2359296,
resolution 11771 x 11771 px/m, cbSize 2359350, bits offset 54

ubuntu@3mdeb:~/dcu$ sudo flashrom -p internal -w read.rom
ubuntu@3mdeb:~/dcu$ sudo reboot

ubuntu@3mdeb:~/dcu$ md5sum img.bmp
844d2884074ad76d0949b30cbd273685  img.bmp
ubuntu@3mdeb:~/dcu$ md5sum /sys/firmware/acpi/bgrt/image
md5sum: /sys/firmware/acpi/bgrt/image: No such file or directory

via cbfstool

ubuntu@3mdeb:~/lcm$ file logo.bmp
logo.bmp: PC bitmap, Windows 3.x format, 800 x 440 x 24, image size 1056000, resolution 3543 x 3543 px/m, cbSize 1056054, bits offset 54
ubuntu@3mdeb:~/lcm$ sudo flashrom -p internal -r read.rom
ubuntu@3mdeb:~/lcm$ sudo cbfstool read.rom add -f logo.bmp -r BOOTSPLASH -n logo.bmp -t raw -c lzma
ubuntu@3mdeb:~/lcm$ sudo flashrom -p internal -w read.rom
ubuntu@3mdeb:~/lcm$ sudo reboot

ubuntu@3mdeb:~/lcm$ md5sum /sys/firmware/acpi/bgrt/image
md5sum: /sys/firmware/acpi/bgrt/image: No such file or directory

Additional context

No response

Solutions you've tried

No response

[miczyg1]

@filipleple have you connected a monitor to the platform? Otherwise the BGRT will not be created if the display is not initialized.

No video output = no logo displayed at boot = no BGRT

Also don't expect the same md5sum of the bitmap file and the image in BGRT. Image in BGRT is stripped from BMP header and is a raw array of pixel values.

[macpijan]

@miczyg1 yes, A 16:9 monitor is plugged in via HDMI and working.

[miczyg1]

@macpijan firmware output also works (can browse setup etc.)? cbmem log in such case would be helpful too

[miczyg1]

I noticed one thing. If this test was done on Ubuntu and DCU has been performed on a binary read directly from flash, DCU will silently fail and report success. The binary read from flash is owned by root (flashrom requires sudo). Trying to manipulate it with cbfstool directly will report an "access denied" error, but DCU does not detect any error.

Secondly, when the bootsplash is changed, I saw

[ERROR] CBFS ERROR: Refusing to decompress unverified file 'logo.bmp' with algo 1 in the cbmem log. It is probably a side-effect of CBFS_VERFICATION. I will have to patch it in coreboot to load from unverified area.

[miczyg1]

CBFS_ALLOW_UNVERIFIED_DECOMPRESSION is the Kconfig option we need, although it is potentially dangerous (BMP file is an external input which can be crafted to cause a DoS and decompress to a huge memory length), Weird that without CBFS_VERFICATION, this is not needed.

[miczyg1]

Dasharo/coreboot#477

[Firminator]

CBFS_ALLOW_UNVERIFIED_DECOMPRESSION is the Kconfig option we need, although it is potentially dangerous (BMP file is an external input which can be crafted to cause a DoS and decompress to a huge memory length), Weird that without CBFS_VERFICATION, this is not needed.

Are you refering to the LogoFAIL vulnerability that was recently presented at BlackHat ( https://i.blackhat.com/EU-23/Presentations/EU-23-Pagani-LogoFAIL-Security-Implications-of-Image_REV2.pdf ) and covered in mainstream media for example @ https://arstechnica.com/security/2023/12/just-about-every-windows-and-linux-device-vulnerable-to-new-logofail-firmware-attack/

@pietrushnic might be a good idea to start have Dasharo firmware components fuzzed either internally or security-audited from an external company?

[mkopec]

It's not quite the same as LogoFAIL, as we don't attempt to load the file from ESP with a hardcoded path automatically like some UEFI vendors. We also only accept uncompressed BMPs and don't have parsers for other image formats

[pietrushnic]

@pietrushnic might be a good idea to start have Dasharo firmware components fuzzed either internally or security-audited from an external company?

That is the goal. I guess HBFA will be presented at DUG#6. However, my perspective on hiring an auditing team or using scanners like binarly differs from one that independent firmware vendors should employ simply because our code, scale, and margins are one to 10^9+. We cannot provide security guarantees at the same level as IBVs should because we cannot afford an audit of 2mln lines of coreboot code and 2mln lines of edk2 code. This should be clear to anyone who seriously understands security economics. The value of Dasharo is not in security guarantees, but in potential security properties, you can get free of charge. If, in any place, we claim we are more secure than any other code base, we probably should rephrase that. Of course, I would like to have a line in Dasharo, which would be like PAX/grsecurity patches, but we are not yet at that level of operation.

[macpijan]

@filipleple Have you confirmed the fix?

[filipleple]

@macpijan yes, as of the new RC with fixes the problem is resolved.