Closed filipleple closed 4 months ago
@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.
@miczyg1 yes, A 16:9 monitor is plugged in via HDMI and working.
@macpijan firmware output also works (can browse setup etc.)? cbmem log in such case would be helpful too
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.
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.
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?
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 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.
@filipleple Have you confirmed the fix?
@macpijan yes, as of the new RC with fixes the problem is resolved.
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
fileScreenshots
via dcu
via cbfstool
Additional context
No response
Solutions you've tried
No response