heads
heads copied to clipboard
linuxboot
add google parrot config
enable google parrot in heads add coreboot and linux config and patch to enable tpm0
@gompa There was a long debate in the past under Heads, where it was decided that ifd could be distributed, where ME couldn't if not already part of the coreboot's blobs and or if the binary redistribution clauses were not clear on that effect. This is why you can find extraction scripts in the blobs dir for boards requiring them.
The idea is that Heads git repository doesn't want to be the redistributor of such blobs. For the xx20 and x230 (maximized) those blobs are downloaded from Lenovo, cleaned, and extracted in the blobs dir. Purism scripts downloads them from their own hosting, having the redistribution liability.
@gompa There was a long debate in the past under Heads, where it was decided that ifd could be distributed, where ME couldn't if not already part of the coreboot's blobs and or if the binary redistribution clauses were not clear on that effect. This is why you can find extraction scripts in the blobs dir for boards requiring them.
The idea is that Heads git repository doesn't want to be the redistributor of such blobs. For the xx20 and x230 (maximized) those blobs are downloaded from Lenovo, cleaned, and extracted in the blobs dir. Purism scripts downloads them from their own hosting, having the redistribution liability.
but the ME and ifd are in the normale coreboot repo : https://github.com/coreboot/blobs/tree/master/mainboard/google/parrot, this is just a nuterd version for more space, but i can remove them if needed
@gompa
user@x230-master:~/heads/build/coreboot-4.13/3rdparty/blobs/mainboard/google/parrot$ ls -al
total 2120
drwxr-xr-x 2 user user 4096 Nov 20 07:01 .
drwxr-xr-x 7 user user 4096 Nov 20 07:01 ..
-rw-r--r-- 1 user user 4096 Nov 20 07:01 descriptor.bin
-rw-r--r-- 1 user user 2093056 Nov 20 07:01 me.bin
-rw-r--r-- 1 user user 65536 Nov 20 07:01 snm_2130_coreboot.bin
Seems like those are redistributable blobs!
@gompa Please run the following in head's recovery shell and post the output to check everything is being measured okay.
source /etc/functions
pcrs
cbmem -1 | grep -B2 -i "pcr 2 measure"
cbfs -l -v 2>&1 | grep "File len\|File name"
second command doesn't return anything so i guess not ?
PCR-00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-02: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-03: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-04: 8A 6A 96 FD E1 A8 DD 96 27 14 79 DC 40 74 2B 36 AB A3 C2 B3 PCR-05: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-06: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 File len : 20 File name : 'cbfs master header' File len : 122d4 File name : 'fallback/romstage' File len : 6800 File name : 'cpu_microcode_blob.bin' File len : 15607 File name : 'fallback/ramstage' File len : 2f6 File name : 'config' File len : 2b9 File name : 'revision' File len : 2ff3 File name : 'fallback/dsdt.aml' File len : 4a4 File name : 'cmos_layout.bin' File len : 50b4 File name : 'fallback/postcar' File len : 70d627 File name : 'fallback/payload' File len : 1b818 File name : '' File len : 10000 File name : 'bootblock'
@gompa There was a long debate in the past under Heads, where it was decided that ifd could be distributed, where ME couldn't if not already part of the coreboot's blobs and or if the binary redistribution clauses were not clear on that effect. This is why you can find extraction scripts in the blobs dir for boards requiring them. The idea is that Heads git repository doesn't want to be the redistributor of such blobs. For the xx20 and x230 (maximized) those blobs are downloaded from Lenovo, cleaned, and extracted in the blobs dir. Purism scripts downloads them from their own hosting, having the redistribution liability.
but the ME and ifd are in the normale coreboot repo : https://github.com/coreboot/blobs/tree/master/mainboard/google/parrot, this is just a nuterd version for more space, but i can remove them if needed
@gompa I would suggest, sincerely and for simplicity, to simply copy paste the code of other blob extraction scripts and implement download and verification logic on hashes obtained from a downloaded blob in repo for a specific commit, and reapply the logic of me_cleaner and verify the hashes of produced blobs dumped inside of your blobs dir, where coreboot config will look for the blobs at each build. Documenting those blobs inside of the board config would also be appreciated. And the build failing because of blobs not existing in tree would both respect the blobs non-redistribution clause, dodging legaility problems, while permitting other users to build easily.
The idea here is that if you implement this in this PR and the extraction tool can be called from command line, your board could then be added into CircleCI's builds, calling your script to download the blobs, neuter them and produce modified IFD matching the verified measurements you have taken to reproduce the same ROM. So each time a new commit lands into master, your board, as all other in CircleCI, will be rebuilt and ROMs produced. Endgoal of this is to have fwupd upgrades in the longer run, when CircleCI builds will have some logic added to be able to validate other builds from other instances and the hashes validated, prior of being uploaded into github releases, and github releases, ingested by LVFS so users can have upgrades of Heads upon new releases.
second command doesn't return anything so i guess not ?
PCR-00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-02: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-03: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-04: 8A 6A 96 FD E1 A8 DD 96 27 14 79 DC 40 74 2B 36 AB A3 C2 B3 PCR-05: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-06: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 File len : 20 File name : 'cbfs master header' File len : 122d4 File name : 'fallback/romstage' File len : 6800 File name : 'cpu_microcode_blob.bin' File len : 15607 File name : 'fallback/ramstage' File len : 2f6 File name : 'config' File len : 2b9 File name : 'revision' File len : 2ff3 File name : 'fallback/dsdt.aml' File len : 4a4 File name : 'cmos_layout.bin' File len : 50b4 File name : 'fallback/postcar' File len : 70d627 File name : 'fallback/payload' File len : 1b818 File name : '' File len : 10000 File name : 'bootblock'
This will require further investigation. PCR2 should have measured Boot block, ROM stage, RAM stage, Heads linux kernel and initrd, so the fact its completely empty is quite concerning.
after adding : CONFIG_TPM_MEASURED_BOOT=y to the coreboot config:
TPM: Digest of FMAP: COREBOOT CBFS: bootblock to PCR 2 logged
TPM: Digest of FMAP: COREBOOT CBFS: fallback/romstage to PCR 2 logged
TPM: Digest of FMAP: COREBOOT CBFS: fallback/postcar to PCR 2 logged
TPM: Digest of FMAP: COREBOOT CBFS: fallback/ramstage to PCR 2 logged
TPM: Write digests cached in TCPA log to PCR
TPM: Write digest for FMAP: COREBOOT CBFS: bootblock into PCR 2
TPM: Write digest for FMAP: COREBOOT CBFS: fallback/romstage into PCR 2
TPM: Write digest for FMAP: COREBOOT CBFS: cmos_layout.bin into PCR 2
TPM: Write digest for FMAP: COREBOOT CBFS: fallback/postcar into PCR 2
TPM: Write digest for FMAP: COREBOOT CBFS: fallback/ramstage into PCR 2
TPM: Extending digest for FMAP: COREBOOT CBFS: cpu_microcode_blob.bin into PCR 2
TPM: Digest of FMAP: COREBOOT CBFS: cpu_microcode_blob.bin to PCR 2 measured
TPM: Extending digest for FMAP: COREBOOT CBFS: fallback/dsdt.aml into PCR 2
TPM: Digest of FMAP: COREBOOT CBFS: fallback/dsdt.aml to PCR 2 measured
TPM: Extending digest for FMAP: COREBOOT CBFS: cmos_layout.bin into PCR 2
TPM: Digest of FMAP: COREBOOT CBFS: cmos_layout.bin to PCR 2 measured
TPM: Extending digest for FMAP: COREBOOT CBFS: fallback/payload into PCR 2
TPM: Digest of FMAP: COREBOOT CBFS: fallback/payload to PCR 2 measured
PCR-2 00f7afb8487a5f8bfaa6fbdb975cbdafec58e07c SHA1 [FMAP: COREBOOT CBFS: bootblock]
PCR-2 a57f7e53ebfdf0e586aa1b33f3b94d0e30c672b3 SHA1 [FMAP: COREBOOT CBFS: fallback/romstage]
PCR-2 d477da5c4846f6dad3ff374bb436c5292b2471e4 SHA1 [FMAP: COREBOOT CBFS: cmos_layout.bin]
PCR-2 0f54280e678346f269d3f5bd35ca1ade1abe3493 SHA1 [FMAP: COREBOOT CBFS: fallback/postcar]
PCR-2 d6ec8bec8d9e8684f646a5a0a64899ec86fda858 SHA1 [FMAP: COREBOOT CBFS: fallback/ramstage]
PCR-2 8efffbbf487c06d4328ce4fbba2314554f2a2925 SHA1 [FMAP: COREBOOT CBFS: cpu_microcode_blob.bin]
PCR-2 e065e93afa3904935395001928da02bac0d81efa SHA1 [FMAP: COREBOOT CBFS: fallback/dsdt.aml]
PCR-2 d477da5c4846f6dad3ff374bb436c5292b2471e4 SHA1 [FMAP: COREBOOT CBFS: cmos_layout.bin]
PCR-2 9e3ab61673c876f1aa35f6c202c6a53ff2090a42 SHA1 [FMAP: COREBOOT CBFS: fallback/payload]
yes ! :
PCR-00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-02: 3D C8 9A F6 49 50 72 A4 91 06 1F 54 F0 72 C3 B6 0F 42 FF 79
PCR-03: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-04: 8A 6A 96 FD E1 A8 DD 96 27 14 79 DC 40 74 2B 36 AB A3 C2 B3
PCR-05: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-06: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
@tlaurion
@gompa I would suggest, sincerely and for simplicity, to simply copy paste the code of other blob extraction scripts and implement download and verification logic on hashes obtained from a downloaded blob in repo for a specific commit, and reapply the logic of me_cleaner and verify the hashes of produced blobs dumped inside of your blobs dir, where coreboot config will look for the blobs at each build. Documenting those blobs inside of the board config would also be appreciated. And the build failing because of blobs not existing in tree would both respect the blobs non-redistribution clause, dodging legaility problems, while permitting other users to build easily.
The idea here is that if you implement this in this PR and the extraction tool can be called from command line, your board could then be added into CircleCI's builds, calling your script to download the blobs, neuter them and produce modified IFD matching the verified measurements you have taken to reproduce the same ROM. So each time a new commit lands into master, your board, as all other in CircleCI, will be rebuilt and ROMs produced. Endgoal of this is to have fwupd upgrades in the longer run, when CircleCI builds will have some logic added to be able to validate other builds from other instances and the hashes validated, prior of being uploaded into github releases, and github releases, ingested by LVFS so users can have upgrades of Heads upon new releases.
this should be done now, please let me know if anything else needs changing
@gompa One nice to have addition for added board not needing external blobs or having redistribution of blobs issue (like here) is to have a CircleCI entree added into .circleci/config.yml:
- run:
name: Download and neuter Parrot ME (keep extracted IFD in tree)
command: |
./blobs/parrot/download_clean_me.sh
- run:
name: Parrot
command: |
rm -rf build/Parrot/* build/log/* && make CPUS=4 V=1 BOARD=Parrot || touch /tmp/failed_build
no_output_timeout: 3h
- run:
name: Output build failing logs
command: |
if [[ -f /tmp/failed_build ]]; then find ./build/ -name "*.log" -type f -mmin -1|while read log; do echo ""; echo '==>' "$log" '<=='; echo ""; cat $log;done; exit 1;else echo "Not failing. Continuing..."; fi
- run:
name: Output Parrot hashes
command: |
cat build/Parrot/hashes.txt \
- run:
name: Archiving build logs for Parrot
command: |
tar zcvf build/Parrot/logs.tar.gz ./build/log/*
- store-artifacts:
path: build/Parrot
Then if you are following your github project from CircleCI, the build will happen on next commit, so you can test built ROM from there. If its functional, we will be able to merge and other Parrot users will be happy.
Are you ok to be added into #692 ? Can you provide some information on the nature of the board there? Thanks!
@tlaurion ah cool wil have to check that out ! sure you can add me to #692. the board is a acer c710 (chromebook Parrot) a basic sandy bridge laptop(there could be a ivy bridge version not a 100% sure about that) it lacks most cpu extentions needed for qubes but this is what i have available, i'd like to try some more recent chromebooks to get heads running on some "cheap" recent hardware with decent batterylife, and i think the chrome book ec is opensource too so that would be a plus
@tlaurion ah cool wil have to check that out ! sure you can add me to #692. the board is a acer c710 (chromebook Parrot) a basic sandy bridge laptop(there could be a ivy bridge version not a 100% sure about that) it lacks most cpu extentions needed for qubes but this is what i have available, i'd like to try some more recent chromebooks to get heads running on some "cheap" recent hardware with decent batterylife, and i think the chrome book ec is opensource too so that would be a plus
@gompa running qubes-hcl-report would resolve the doubts with clear viww out of dom0 console over qubesos. Otherwise, its just speculations.
@tlaurion ah cool wil have to check that out ! sure you can add me to #692. the board is a acer c710 (chromebook Parrot) a basic sandy bridge laptop(there could be a ivy bridge version not a 100% sure about that) it lacks most cpu extensions needed for qubes but this is what i have available, i'd like to try some more recent chromebooks to get heads running on some "cheap" recent hardware with decent batterylife, and i think the chrome book ec is opensource too so that would be a plus
@gompa running qubes-hcl-report would resolve the doubts with clear viww out of dom0 console over qubesos. Otherwise, its just speculations.
when booting the qubes installer from usb it gives an error about unsupported hardware, missing features IOMMU/VT-d/AMD-Vi,Interupt Remapping missing vt-d is confirmed by the intel arkpage: https://ark.intel.com/content/www/us/en/ark/products/56056/intel-celeron-processor-847-2m-cache-1-10-ghz.html support for this chromebook has ended, most info i found on other still supported chromebooks stated they have intel vt-d enabled
@tlaurion i cleaned up the board config, could you please check if the ci config is correct like this, its a direct copy of the snippet above but i cant test
@gompa Sorry. Got lost in time.
Created branch https://github.com/tlaurion/heads/tree/gompa_parrot which should trigger the CircleCI build https://app.circleci.com/pipelines/github/tlaurion/heads/717/workflows/d2423e2b-21a3-4a7f-b86c-fb0a55981d85/jobs/864
But CircleCI builds are foo bar for the moment. Too many boards and parallelization is needed at this point. Blockers #977 #935 to gain precious compilation time.
@gompa meanwhile, Heads community in not really loving PRs with many commits (I do. I think this board is the exact example of how to add a new boards into Heads).
@MrChromebox : Would you be ok with merging so many commits directly? @gompa I could squash, but that removes the credit to you and the steps taken to make it work, while this PR would show the individual commits.
@tlaurion absolutely not, this definitely needs cleanup.
Additionally, I'm not certain this will work for all Parrot boards given there are both SNB/IVB versions, which I believe use different ME firmware. I can get away with it for my MrChromebox UEFI firmware since I don't reflash the ME
@gompa Current state of this PR prior of merge:
- [ ] Apply changes based on reviews, including this parrot specific version
- [ ] Clean the commit history (or create another PR based on master and add just add the patch board and configs. I would prefer that since this PR is a really good example of how to add a coreboot supported board inside of Heads, for prosperity)
- [ ] Review
- [ ] Merge