-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document how to investigate reproducibility issues #70
Comments
Heads is not reproducible from same debian-10 host base (CircleCI docker vs QubesOS debian-10 base).
So the full 12mb rom and bottom SPI rom are different. Here is where hashes.txt shows build binaries differences between the builds:
Where we don't really care about gawk being different, and where tools.cpio is the output prior of compression of other tools not being reproducible. |
Then to compare local to CircleCI artifacts, you need to download and extract what was packaged (initrd.cpio.xz) and compare it with local build in case of mismatch of rom images signatures. We are interested here into commit linuxboot/heads@9339394 (9339394 commit id. Note: appended into rom name).
Now lets compare: Remote:
Local:
Will do one diffoscope per binaries |
veritysetup difference between 2 debian-10 hosts with different paths of builds:
|
cryptsetup difference between 2 debian-10 hosts with different paths of builds:
|
cryptsetup-reencrypt difference between 2 debian-10 hosts with different paths of builds:
|
libblkid.so.1 difference between 2 debian-10 hosts with different paths of builds is too big to output here. |
busybox difference between 2 debian-10 hosts with different paths of builds is too big to output here. mainly, time of compilation is injected, all address of code is shifted, including entry point. |
@osresearch @flammit : any troubleshooting insights would be amazing for the community. Otherwise I'll try to fix when I have time... |
@tlaurion I don't know how precisely CI looks like, but you know my rambling about reproducible builds. The only feasible paths are Nix/Guix related and having reproducible build environment. This moves very slow because everyone is short on time. Anyway Dasharo has this on roadmap and have to address the issue.I gathered some thoughts to have one point to which I can reference people when reproducibility problem arise: https://docs.dasharo.com/osf-trolling-list/build_process/ |
@pietrushnic This seems to exactly be the problem here, with cryptsetup and busybox being reproducible in the past but having broke reproducibility recently, where I do not quite understand without further digging. What happened and why RPATHs are now introduced in the cryptsetup binaries and libs, where they weren't before :
As for coreboot layer, those are now again reproducible (was not in the past, relaying on musl-cross-make, now relaying on coreboot buildstack per coreboot version) which is now "pinned" per version of coreboot; specified in the board configuration. So yeah. We have all libraries and binaries outside of coreboot being built against musl-cross-make and local host toolchain. Seems like host toolchain introduced changes.... again. CI is over here based on current CircleCI config:
|
@pietrushnic Innteresting! NixOS/nixpkgs#128592 |
Notes on resolving reproducibility issues, just because some questions were asked over slack and wanted to keep track |
Yes, I know @felixsinger works on that. Please note there will be stable toolchains of coreboot, based on recent decisions of coreboot leadership. More to that there would be stability checks also. So things going in very good direction. Please check notes: |
For anyone else interested: see notes from 30 June 2021 forward |
Redid the test as part of passing O2->Os (in the goal of reducing modules footprint at the cost of performance) The list of non-reproducible binaries grows. Here is the small script I came up with, having a local board build under ~/heads while having dumped CircleCI hashes.txt for the same board under a local directory (/tmp/circleci_cryptsetup_for_all here): cat ./output_non_reproducible shows:
Where the following pinpoints to the possible modules being responsible to produce such binaries: Which produces the following (not completely valid) list:
The curated version of output_non_reproducible file produces following modules now being non-reproducible modules:
|
@jans23 @MrChromebox : do we do plan together to resolve this sharing knowledge we have in the area to bring back reproducible builds?
|
And would also gladly and proactively document such process in the contribute section and also learn my way with such paid mentorship. |
Maybe we could look at hotp-verification but currently no time for others, unfortunately. :-( |
One technique I've found useful is to have a unique string in the build path and then grep through the various outputs for it. This found that json-c was including some paths for the musl headers, and that in turn causes cryptsetup2 to be irreproducible. cryptsetup1 ignores the busybox should be fixed by #74 or by adding haven't gotten to the others yet |
One of my thoughts for ensuring reproducibility is to have two CI runners with different base OS images and require that they produce the same firmware images for any commits. That will double the CPU required, although it is important to catch these early rather than after things have bit-rotted or when someone asks "hey, when did this break?". |
A few other important things:
|
Anything using wild cards is suspect... it looks like lvm2 might have a problem in its makefile that globs the exported symbols: osresearch/linux-builder#6 gnu make has sorted, then unsorted, and then sorted again: https://savannah.gnu.org/bugs/index.php?52076 |
As of today, linuxboot/heads#1367 fixed json-c. Here are the current reproducibility issues between local and CircleCI builds (both debian-11 based) at the moment of merging that PR (when using fbwhiptail):
So the following heads modules needs work/patching:
Which causes tools.cpio (where linux libaries and binaries are packed) and initrd.cpio.xz (where tools.cpio, modules.cpio and heads.cpio are compressed) to be non-reproducible and consequently the final rom. |
Thanks for excellent writeup @tlaurion ! Is |
So, I have managed to overcome my debian 11 issues and it seems that I was able to reproduce libgcrypt 1.10.1 build from CI on a freshly deployed Debian 11 amd64 virtual machine:
|
LATEST UPDATE IS THAT THE FOLLOWING MODULES ARE NOT REPRODUCIBLE (02/24/2022):
Expend from linuxboot/heads#927 (comment)
The text was updated successfully, but these errors were encountered: