Dasharo
Dasharo (coreboot+UEFI) for Odroid H4+ is not reproducible
Component
Dasharo firmware
Device
Hardkernel Odroid H4
Dasharo version
v0.9.0
Dasharo Tools Suite version
No response
Test case ID
No response
Brief summary
After following build manual I get different hash than one published on website.
How reproducible
No response
How to reproduce
- Follow build manual for v0.9.0
- Compare the hash of the build with one published on a website here
Expected behavior
The hash should match.
Actual behavior
The hash does not match.
Expected:
ac285ed4dbda35b76c2754afbb3d7dae176cebfc507461f327ea4a3932e19270
Obtained:
9170192c6e41df15476ea581e456b7ac014830ecb9e7b58b1db24f9a5617785f
Screenshots
No response
Additional context
https://github.com/Dasharo/romscope/issues/3
Solutions you've tried
No response
We should consider BUILD_TIMELESS; otherwise, change in the commit from which we build this version affects reproducibility.
We should consider
BUILD_TIMELESS; otherwise, change in the commit from which we build this version affects reproducibility.
I don't quite understand. A change in the commit should result in different binary, right? Assuming it touches the firmware code in a way that it changes its behavior.
We don't use TIMELESS builds to have a valid date in the SMBIOS tables.
@pietrushnic also you haven't used the right HASH file. The correct one for manual builds are these prefixed with dev_signed: https://dl.3mdeb.com/open-source-firmware/Dasharo/hardkernel_odroid_h4/v0.9.0/hardkernel_odroid_h4_v0.9.0_dev_signed.rom.sha256
This hash gives 9170192c6e41df15476ea581e456b7ac014830ecb9e7b58b1db24f9a5617785f so it is was is expected.
These are signed by publicly available, static vboot dev keys. What you have checked the signature against, is the binary signed by 3mdeb vboot keys, which are not available anywhere publicly. Obviously, you can't achieve the same hash.
We should consider
BUILD_TIMELESS; otherwise, change in the commit from which we build this version affects reproducibility.I don't quite understand. A change in the commit should result in different binary, right? Assuming it touches the firmware code in a way that it changes its behavior.
We don't use TIMELESS builds to have a valid date in the SMBIOS tables.
@pietrushnic also you haven't used the right HASH file. The correct one for manual builds are these prefixed with dev_signed: https://dl.3mdeb.com/open-source-firmware/Dasharo/hardkernel_odroid_h4/v0.9.0/hardkernel_odroid_h4_v0.9.0_dev_signed.rom.sha256 This hash gives
9170192c6e41df15476ea581e456b7ac014830ecb9e7b58b1db24f9a5617785fso it is was is expected.These are signed by publicly available, static vboot dev keys. What you have checked the signature against, is the binary signed by 3mdeb vboot keys, which are not available anywhere publicly. Obviously, you can't achieve the same hash.
Build time will bleed in builds if BUILD_TIMELESS not set, preventing reproducible builds of same commit, no?
Release builds could tune out BUILD_TIMELESS only for releases, which would not prevent reproducible builds of same commit in the future.
Build time will bleed in builds if BUILD_TIMELESS not set, preventing reproducible builds of same commit, no?
coreboot takes the commit date so it any given git rev should produce the same results at any time That said, it also takes the latest git tag from git describe and inserts it into the COREBOOT_VERSION string, I think that is more problematic for reproducibility
i.e. if somebody tags commit a for release and then another tag is placed on the same commit, subsequent builds might have a different COREBOOT_VERSION. Someone could also not have all the tags pulled to their local git repo
(not to mention that it's just weird to see protectli_vault_adln_v0.9.0-rc7-12-gf8e8d9498a63 in my clevo/nv4x_tgl build)
@pietrushnic also you haven't used the right HASH file. The correct one for manual builds are these prefixed with dev_signed: https://dl.3mdeb.com/open-source-firmware/Dasharo/hardkernel_odroid_h4/v0.9.0/hardkernel_odroid_h4_v0.9.0_dev_signed.rom.sha256 This hash gives 9170192c6e41df15476ea581e456b7ac014830ecb9e7b58b1db24f9a5617785f so it is was is expected.
What is the reason we don't link those here: https://docs.dasharo.com/variants/hardkernel_odroid_h4/releases/#v090-2025-02-20 ?
These are signed by publicly available, static vboot dev keys. What you have checked the signature against, is the binary signed by 3mdeb vboot keys, which are not available anywhere publicly. Obviously, you can't achieve the same hash.
Yes, this is obvious to me, but how would I know those hashes coming from that build? And how would I know where to find dev-signed hashes? I am genuinely asking because maybe we should have it documented somewhere and link it in the release template.
@mkopec I picked that battle in some places:
- https://github.com/Dasharo/dasharo-pq/blob/rel_24.08.00.01/patches/libpayload-make-reproducible-by-using-ffile-preifx-map
- https://github.com/Dasharo/dasharo-pq/blob/rel_24.08.00.01/patches/makefile.mk-if-in-git-repository-use-git-describe-for-kernelversion.patch
- old stuff from @krystian-hebel https://github.com/Dasharo/dasharo-pq/blob/rel_24.08.00.01/patches/0034-payloads-iPXE-option-for-reproducible-building.patch
@pietrushnic also you haven't used the right HASH file. The correct one for manual builds are these prefixed with dev_signed: https://dl.3mdeb.com/open-source-firmware/Dasharo/hardkernel_odroid_h4/v0.9.0/hardkernel_odroid_h4_v0.9.0_dev_signed.rom.sha256 This hash gives 9170192c6e41df15476ea581e456b7ac014830ecb9e7b58b1db24f9a5617785f so it is was is expected.
What is the reason we don't link those here: https://docs.dasharo.com/variants/hardkernel_odroid_h4/releases/#v090-2025-02-20 ?
Good question. I have generated the release notes templates again and the links to dev_signed hashes are there. It just seems like @filipleple didn't use the templates and did some manual work here: https://github.com/Dasharo/docs/pull/1000 I didn't catch it, because I assumed the templates were used (which I reviewed and were good, so should give 100% good release notes), which should eliminate human errors. Can't trust people to just use automated scripts and copy-paste the result...
These are signed by publicly available, static vboot dev keys. What you have checked the signature against, is the binary signed by 3mdeb vboot keys, which are not available anywhere publicly. Obviously, you can't achieve the same hash.
Yes, this is obvious to me, but how would I know those hashes coming from that build? And how would I know where to find dev-signed hashes? I am genuinely asking because maybe we should have it documented somewhere and link it in the release template.
I believe I answered it here: https://github.com/Dasharo/romscope/issues/3#issuecomment-2678075253 tl;dr poor or lack of documentation at all.
I believe I answered it here: https://github.com/Dasharo/romscope/issues/3#issuecomment-2678075253 tl;dr poor or lack of documentation at all.
Yes, I saw your answer after I wrote this comment.
Good question. I have generated the release notes templates again and the links to dev_signed hashes are there. It just seems like @filipleple didn't use the templates and did some manual work here: https://github.com/Dasharo/docs/pull/1000 I didn't catch it, because I assumed the templates were used (which I reviewed and were good, so should give 100% good release notes), which should eliminate human errors. Can't trust people to just use automated scripts and copy-paste the result...
Yes, but it doesn't work like that. Teaching procedures are not like "here is the paper please follow" if that were the case, we would just give instructions for the plane to pilots or boot about doing heart surgery and expect effective action. Let's try to deal with it internally and see how we can improve the overall process.
Started addressing my review on https://github.com/Dasharo/coreboot/pull/619
I will make AIRGAP and TIMELESS build available everywhere. Then also similar PR will go to most recent dasharo branch
https://github.com/Dasharo/coreboot/pull/619 merged.
Now have to move it to main dasharo branch too, then the issue can be closed.