Re: [coreboot] Reproducible builds
Hi Tom, only the coreboot region itself should be reproducible. The BIOS flash contains multiple regions (or call them "partitions"). Only the bios region, which contains coreboot and the payloads is reproducible. And so far I know, only SeaBIOS as payload is reproducible. GRUB might be reproducible, but I'vn't tracked the reamining issues there. Those might have been fixed. > I found the config used, > https://github.com/coreboot/coreboot/blob/master/configs/builder/config.lenovo_x230, > > does not include payloads and that the IFD, ME and GBE binaries were > sourced from "./site-local/" but I cannot find these files in any > public repo. If these are not available, then the generated hashes > cannot be confirmed outside of the reproducible-builds Jenkins > environments. Those 3 files needs to be extracted from the BIOS chip. Here is an example, how the layout of a sandy/ivy machine look like: 0 MB --- | IFD | --- | GBE | --- | ME | --- | BIOS| --- 12 MB > > My question ultimately comes down to how much of Coreboot is > reproducible and can a complete binary with payloads be built > consistently given the same build enviroment? The more specific > question is, if the downloading the Coreboot 4.8.1 release using this > config, > https://github.com/Thrilleratplay/coreboot-builder-scripts/blob/master/x230/config-4.8.1, > > why would the SHA256 hashes never match and, at times, cbfstool > partition sizes vary? That's a good question, it shouldn't! Sounds like a bug in our versions script. You can try out diffoscope to find more about the reproducible builds issue. There is also a website around diffoscope, so you don't have to install the toolsuite on your machine. https://try.diffoscope.org/ Best, lynxis pgpr_11tw_Owi.pgp Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Reproducible builds
Hi, I am trying to make a series of scripts with configs to help simplify the Coreboot build process for the Lenovo X230, and soon the X220, using the Coreboot-sdk Docker image. The one issue I am having is creating consistent builds. This was confusing after heading the news that Coreboot was reproducible and finding that the x230 was one of the many models confirmed here: https://tests.reproducible-builds.org/coreboot/coreboot.html. After doing some digging through the Coreboot git repo and searching gerrit, I found the config used, https://github.com/coreboot/coreboot/blob/master/configs/builder/config.lenovo_x230, does not include payloads and that the IFD, ME and GBE binaries were sourced from "./site-local/" but I cannot find these files in any public repo. If these are not available, then the generated hashes cannot be confirmed outside of the reproducible-builds Jenkins environments. My question ultimately comes down to how much of Coreboot is reproducible and can a complete binary with payloads be built consistently given the same build enviroment? The more specific question is, if the downloading the Coreboot 4.8.1 release using this config, https://github.com/Thrilleratplay/coreboot-builder-scripts/blob/master/x230/config-4.8.1, why would the SHA256 hashes never match and, at times, cbfstool partition sizes vary? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot reproducible builds almost there
Great! So there were no coreboot patches necessary for this? Is it just a matter of preparing the right build environment? Because when I tried to do it manually (with SeaBios) it didn't produce the same bytes. Since SeaBios is reproducible it would be great to make the coreboot + SeaBios bundle reproducible too. And if the bundle is reproducible then it is easy to have a script that *verifies* some external build. Assuming it included the CONFIG values, one could extract the .config file from the rom (something like grep -a CONFIG_ rom .config), do a local build and compare the bytes. I guess one new CONFIG value would be the SeaBios version. --emi On Thu, Jun 11, 2015 at 8:58 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear coreboot folks, Am Donnerstag, den 26.02.2015, 17:23 +0200 schrieb Emilian Bold: I was trying to duplicate a coreboot build back in November and I noticed I couldn't get my ROM file to be identical to the one I found online. It seems that coreboot doesn't have reproducible builds yet. Debian has been looking into this for a while https://wiki.debian.org/ReproducibleBuilds and I think coreboot should adopt this concept. […] Holger Levsen joined #coreb...@irc.freenode.net yesterday to report that he integrated coreboot into the reproducible builds infrastructure [1]. After configuring the used build script [2] to build without a payload, nice ionice -c 3 \ bash util/abuild/abuild --payloads none || true # don't fail the full job just because some targets fail it looks like most boards are passing the test now [1]. Big thanks to Alexander (lynxis) for submitting the necessary patches! The only exceptions are the six boards below. * a-trend_atc-6220 (256K) is unreproducible. * a-trend_atc-6240 (256K) is unreproducible. * google_nyan (4096K) is unreproducible. * google_nyan_big (4096K) is unreproducible. * google_rush (4096K) is unreproducible. * google_rush_ryu (8192K) is unreproducible. Also, as a side node, SeaBIOS also supports to be built reproducible since commit 624e8127 (build: Support make VERSION=xyz to override the default build version) [3], though not by default. So the coreboot build system, building the SeaBIOS payload, would need to be adapted, if a reproducible build with the SeaBIOS payload is required. Thanks, Paul [1] https://reproducible.debian.net/coreboot/coreboot.html [2] http://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/reproducible_coreboot.sh [3] http://seabios.org/pipermail/seabios/2015-June/009253.html -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Reproducible-builds] coreboot reproducible builds almost there
Hi, On Donnerstag, 11. Juni 2015, Patrick Georgi wrote: Things is, _AIUI_, there is no common payload which can be enabled for all boards. Is that correct? The one that should run everywhere is Google's depthcharge, and that isn't hooked up to the build system like SeaBIOS is (and even depthcharge isn't available for emulation/qemu-riscv). So you're correct, there is no single payload for every board. ok. Since we select default payloads in our Kconfig rules (seabios for x86), I guess we should start doing the same for other architectures. I don't think that belongs in your test script - things might change in the future, and that shouldn't require additional effort on your part. agreed :) We'll work on that, and will tell you once there's a plan and/or implementation. cool, thanks. That said, as the current tests have reached 100%, I'm thinking about removing the --payloads none switch again now already, so that then some images have payloads and some not. And then I'm wondering, what next? AIUI you don't ever offer images for download and instead expect users to build coreboot themselves. So the whole topic of verifying and reproducing the vendors (=your!) binaries is a bit mood here, at least atm. Any comments on that? There are distributions, sort of. Google ships coreboot as part of Chrome OS (which requires a huge build system even to build just coreboot). Then there's libreboot (www.libreboot.org), which ships their coreboot-variant (without blobs and with as few patches against coreboot as possible) with GRUB2 as payload for a small selection of boards that they can support. There are also some other vendors, but they're less visible. Hm. I guess I will leave it here for the moment, hoping that someone will pick up the task of verifying actually released and downloadable images... If you want to support coreboot distributions (that ship binaries), libreboot is currently your best bet. added as question to my TODO :) Last, and probably least: currently the headline of the page says fast, flexible and reproducible Open Source firmware_?_ which I felt was appropriate when only a few images with payload were reproducible. Oh, I loved it, still do! At some point we should replace the question mark with an exclamation mark, though :-) :-) I've change the code to exchange the question mark against an exclaimation mark if 100% are reached... :) Oh, and as the page says, it's currently only updated once a month and on demand, so please do ping me if you merged some reproducible changes into master! Thanks, will do. Let's start immediately :-) Since you mentioned 'once we reach 100% (without payloads)' earlier: the issue of the remaining 7 non-reproducible board should be fixed since today, in response to your report. I'd appreciate if you could do another run to verify this. https://jenkins.debian.net/view/reproducible/job/reproducible_coreboot/44/console has just finished and https://reproducible.debian.net/coreboot/coreboot.html now says 248 (100.0%) out of 248 built coreboot images were reproducible in our test setup - kudos!! cheers, Holger signature.asc Description: This is a digitally signed message part. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot reproducible builds almost there
2015-06-11 10:25 GMT+02:00 Holger Levsen hol...@layer-acht.org: I'm now wondering how to proceed further. I *believe* another set of tests, this time with payloads, would be useful, if only to prove that the combination reproducible coreboot plus reproducible payload also is reproducible. Things is, _AIUI_, there is no common payload which can be enabled for all boards. Is that correct? The one that should run everywhere is Google's depthcharge, and that isn't hooked up to the build system like SeaBIOS is (and even depthcharge isn't available for emulation/qemu-riscv). So you're correct, there is no single payload for every board. If it is, is there another way to sensible group targets by payloads or detect sensible ones? Currently I'm building all targets in one pass using abuild, but I could also loop through each target and build it individually, as long as I dont have to configure 247 different configurations... (rather easy would be, all i386 targets use seabios, all mips target $that_one and all arm targets $another_one... Since we select default payloads in our Kconfig rules (seabios for x86), I guess we should start doing the same for other architectures. I don't think that belongs in your test script - things might change in the future, and that shouldn't require additional effort on your part. We'll work on that, and will tell you once there's a plan and/or implementation. And then I'm wondering, what next? AIUI you don't ever offer images for download and instead expect users to build coreboot themselves. So the whole topic of verifying and reproducing the vendors (=your!) binaries is a bit mood here, at least atm. Any comments on that? There are distributions, sort of. Google ships coreboot as part of Chrome OS (which requires a huge build system even to build just coreboot). Then there's libreboot (www.libreboot.org), which ships their coreboot-variant (without blobs and with as few patches against coreboot as possible) with GRUB2 as payload for a small selection of boards that they can support. There are also some other vendors, but they're less visible. If you want to support coreboot distributions (that ship binaries), libreboot is currently your best bet. Last, and probably least: currently the headline of the page says fast, flexible and reproducible Open Source firmware_?_ which I felt was appropriate when only a few images with payload were reproducible. Oh, I loved it, still do! At some point we should replace the question mark with an exclamation mark, though :-) Oh, and as the page says, it's currently only updated once a month and on demand, so please do ping me if you merged some reproducible changes into master! Thanks, will do. Let's start immediately :-) Since you mentioned 'once we reach 100% (without payloads)' earlier: the issue of the remaining 7 non-reproducible board should be fixed since today, in response to your report. I'd appreciate if you could do another run to verify this. Regards, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot reproducible builds almost there
Dear coreboot folks, Am Donnerstag, den 26.02.2015, 17:23 +0200 schrieb Emilian Bold: I was trying to duplicate a coreboot build back in November and I noticed I couldn't get my ROM file to be identical to the one I found online. It seems that coreboot doesn't have reproducible builds yet. Debian has been looking into this for a while https://wiki.debian.org/ReproducibleBuilds and I think coreboot should adopt this concept. […] Holger Levsen joined #coreb...@irc.freenode.net yesterday to report that he integrated coreboot into the reproducible builds infrastructure [1]. After configuring the used build script [2] to build without a payload, nice ionice -c 3 \ bash util/abuild/abuild --payloads none || true # don't fail the full job just because some targets fail it looks like most boards are passing the test now [1]. Big thanks to Alexander (lynxis) for submitting the necessary patches! The only exceptions are the six boards below. * a-trend_atc-6220 (256K) is unreproducible. * a-trend_atc-6240 (256K) is unreproducible. * google_nyan (4096K) is unreproducible. * google_nyan_big (4096K) is unreproducible. * google_rush (4096K) is unreproducible. * google_rush_ryu (8192K) is unreproducible. Also, as a side node, SeaBIOS also supports to be built reproducible since commit 624e8127 (build: Support make VERSION=xyz to override the default build version) [3], though not by default. So the coreboot build system, building the SeaBIOS payload, would need to be adapted, if a reproducible build with the SeaBIOS payload is required. Thanks, Paul [1] https://reproducible.debian.net/coreboot/coreboot.html [2] http://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/reproducible_coreboot.sh [3] http://seabios.org/pipermail/seabios/2015-June/009253.html signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot reproducible builds almost there
2015-06-11 7:58 GMT+02:00 Paul Menzel paulepan...@users.sourceforge.net: Holger Levsen joined #coreb...@irc.freenode.net yesterday to report that he integrated coreboot into the reproducible builds infrastructure [1]. Thank you for the heads up, and thanks Holger for doing it! * a-trend_atc-6220 (256K) is unreproducible. * a-trend_atc-6240 (256K) is unreproducible. * google_nyan (4096K) is unreproducible. * google_nyan_big (4096K) is unreproducible. * google_rush (4096K) is unreproducible. * google_rush_ryu (8192K) is unreproducible. The problem is one of collation order configured by LANG (see their build script). fr_CH.UTF-8 has different rules that sort A_TREND before AAEON instead of after ASUS, and NYAN before instead of after NYAN_*. http://review.coreboot.org/10510 should deal with that. While at it, http://review.coreboot.org/10512 minimizes the stored config to make it clearer to users which options were changed. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot reproducible builds
SeaBIOS requires one patch. https://github.com/lynxis/seabios/commit/487ef74fc6cb1b1020fb25c9bb3f166602ca926c Yes, SeaBIOS seems to have a surprisingly clean build system. Could you make a pull request with that commit? --emi On Fri, Mar 6, 2015 at 5:19 AM, Alexander Couzens lyn...@fe80.eu wrote: Hi Emilian, I chatted today with Holger from reproducible.debian.net and couldn't resist doing reproducible builds ;). These patches need additonal work, but they are working when the git tree is clean. You can test coreboot reproducible when building without payload. Or a more advanced way integrate my seabios git-tree into coreboot's payload target. coreboot needs 2 patches (one is very dirty ;) to build reproducible. http://review.coreboot.org/#/c/8611/ http://review.coreboot.org/#/c/8612/ SeaBIOS requires one patch. https://github.com/lynxis/seabios/commit/487ef74fc6cb1b1020fb25c9bb3f166602ca926c Best, lynxis -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot reproducible builds
Hi Emilian, I chatted today with Holger from reproducible.debian.net and couldn't resist doing reproducible builds ;). These patches need additonal work, but they are working when the git tree is clean. You can test coreboot reproducible when building without payload. Or a more advanced way integrate my seabios git-tree into coreboot's payload target. coreboot needs 2 patches (one is very dirty ;) to build reproducible. http://review.coreboot.org/#/c/8611/ http://review.coreboot.org/#/c/8612/ SeaBIOS requires one patch. https://github.com/lynxis/seabios/commit/487ef74fc6cb1b1020fb25c9bb3f166602ca926c Best, lynxis pgpnBOIcmQV8V.pgp Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot reproducible builds
2015-02-26 16:23 GMT+01:00 Emilian Bold emilian.b...@gmail.com: It seems that Coreboot doesn't have reproducible builds yet. You're right, it doesn't. One of the major items is probably to replace the current build time stamps with something more reasonable. For example, the current commit's time stamp (unless the tree is dirty, in which reproducability is impossible). I think Coreboot should adopt this concept. Patches accepted. It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've noticed is that even if I extract the CONFIG_ values the build still needs some manual tweaking. Ideally we should record the tools used (crossgcc version, etc), the We do. coreboot git revision id, We do. the CONFIG_ values and the build info for the We optionally do. payloads (for the auto-downloaded SeaBIOS I think just the git revision id would be enough). Payloads are more intricate. I'd stick with the coreboot parts, that is, a coreboot build without adding a payload is bit-identical. Then do the same for the payload (we can add meta-data to cbfs files or store payload information in a separate cbfs file). Is there anyone willing to help me with this (or already working on this)? Like Peter I'm happy to review changesets on gerrit. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot reproducible builds
On Thu, Feb 26, 2015 at 8:10 AM, Patrick Georgi via coreboot coreboot@coreboot.org wrote: 2015-02-26 16:23 GMT+01:00 Emilian Bold emilian.b...@gmail.com: It seems that Coreboot doesn't have reproducible builds yet. You're right, it doesn't. One of the major items is probably to replace the current build time stamps with something more reasonable. For example, the current commit's time stamp (unless the tree is dirty, in which reproducability is impossible). There are two facets to this issue: - when an image needs to built from source, we want the binary to be the same. In case the tree is dirty we might include a hash of the tree diffs against the top SHA1, just a thought. - build always recompiles some files and relinks the image, even if there is not source code changes. Is this really necessary, shouldn't make just do nothing in case the source did not change? --vb I think Coreboot should adopt this concept. Patches accepted. It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've noticed is that even if I extract the CONFIG_ values the build still needs some manual tweaking. Ideally we should record the tools used (crossgcc version, etc), the We do. coreboot git revision id, We do. the CONFIG_ values and the build info for the We optionally do. payloads (for the auto-downloaded SeaBIOS I think just the git revision id would be enough). Payloads are more intricate. I'd stick with the coreboot parts, that is, a coreboot build without adding a payload is bit-identical. Then do the same for the payload (we can add meta-data to cbfs files or store payload information in a separate cbfs file). Is there anyone willing to help me with this (or already working on this)? Like Peter I'm happy to review changesets on gerrit. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot reproducible builds
Emilian Bold wrote: It seems that Coreboot doesn't have reproducible builds yet. That is correct. Ideally Yep. Is there anyone willing to help me with this (or already working on this)? Yes, I am willing to help you review your patches when they are in Gerrit. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Coreboot reproducible builds
Hello, I was trying to duplicate a coreboot build back in November and I noticed I couldn't get my ROM file to be identical to the one I found online. It seems that Coreboot doesn't have reproducible builds yet. Debian has been looking into this for a while https://wiki.debian.org/ReproducibleBuilds and I think Coreboot should adopt this concept. It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've noticed is that even if I extract the CONFIG_ values the build still needs some manual tweaking. Ideally we should record the tools used (crossgcc version, etc), the coreboot git revision id, the CONFIG_ values and the build info for the payloads (for the auto-downloaded SeaBIOS I think just the git revision id would be enough). If the timestamps and such are cleaned we should get a reproducible ROM. Is there anyone willing to help me with this (or already working on this)? --emi -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
