add google parrot config

[gompa]

enable google parrot in heads
add coreboot and linux config and patch to enable tpm0

[tlaurion]

@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]

@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

[tlaurion]

@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!

[Tonux599]

@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"

[gompa]

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'

[tlaurion]

@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.

[Tonux599]

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.

[gompa]

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]

[Tonux599]

@gompa sorry can you just confirm that pcrs show PCR-2 being populated?

[gompa]

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 

[gompa]

@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

[tlaurion]

A note here on how you obtained and reproduced the shrinked ifd would be helpful for people wanting to reproduce.

[tlaurion]

@gompa would still be required!

[tlaurion]

Havent checked the specs of platform but no GBE in rom means that creating a full rom like we do here with ME and ifd results in the equivalent of a maximized board.

Putting ME and creating an expended ifd taking advantage of the freed space means that the IFD put into repo is unlocked with ifdtool. is that the case? If so it should be documented properly, stating how the result was obtained.

If such, the flashrom upgrade line into board config should remove --ifd --image BIOS as in maximized boards configs

Question is: you were successful flashing it externally with ifd and ME included in coreboot image? If there is no Ethernet port (I read eth0 somethwere... No need for a gbe blob?), and then no GBE region needed here, then it is candidate for maximized board and the flash options below should be changed accordingly. If there is eth0, its not e1000e based?

Otherwise, if IFD was not unlocked (for some reason) and we do not want to be able to upgrade ME later on or reflash whole SPI region internally, leave it be with specifying --ifd --image BIOS below. This means that on firmware future internal firmware upgrades, only the BIOS region (fixed in both ifd provided matching CBFS_REGION in coreboot config) will be modifiable. If ME is upgraded in repo later on, and IFD was not unlocked, it means that external reflashing would be required to write ifd, ME changing size.

[gompa]

Question is: you were successful flashing it externally with ifd and ME included in coreboot image? If there is no Ethernet port (I read eth0 somethwere... No need for a gbe blob?), and then no GBE region needed here, then it is candidate for maximized board and the flash options below should be changed accordingly. If there is eth0, its not e1000e based?

yeah i was succesfull flashing it externaly, first time i flashed it internaly i "bricked" it. (probably locked ifd)
the nic is a tg3 broadcom card and i dont think it needs a gbe blob

Otherwise, if IFD was not unlocked (for some reason) and we do not want to be able to upgrade ME later on or reflash whole SPI region internally, leave it be with specifying --ifd --image BIOS below. This means that on firmware future internal firmware upgrades, only the BIOS region (fixed in both ifd provided matching CBFS_REGION in coreboot config) will be modifiable. If ME is upgraded in repo later on, and IFD was not unlocked, it means that external reflashing would be required to write ifd, ME changing size.

the ifd is not unlocked mostly because i forgot to unlock it and flashed it externaly , i could unlock it ? i dont know what's prefered

[tlaurion]

@gompa: Other boards (non maximized) take into consideration that blobs are extracted from backups (could be another script called extract, as in x230 maximized blobs dir), where the script calls ifdtool -u by default, where the user can decide for himself to not unlock it.

If the goal is to have maintained fwupd board, where a new commit of Heads could lead to new ME bin in coreboot in newer coreboot version, then only unlocked ifd with corrected new maximized free space + updated ME (from unlocked region) would permit such upgrade. (Code is pending review under QubesOS and FWUPD as of right now, where helper script will need to be developped under Heads to verify and ask user to flash on later version.)

Not unlocking ifd means that the board config would need to stay as is only specifying BIOS to be flashable, where future ME upgrade (if that is even a thing, I have not researched this board at all) would require the board to be externally reflashed. Is there a screw that needs to be unscrewed to flash SPI? I have no idea here, so I leave you the choice of implementation.

In all case, if we want a fully upgradeable ROM from fwupd, it would need ifd to be unlocked.
There is no consensus on this as of now and there was debates on the subject before around, if you look. My opinion is that IFD should be unlocked so whole SPI can be inspected/upgraded.

[tlaurion]

Change to "--force --noverify-all -p internal" if BIOS image is complete, and no GBE is needed (so that we can internally reflash everything from within Heads, the whole SPI flash; not just the BIOS region).

If GBE image needed, another extraction script needs to be put in blobs directory, so that the user has to run it to extract his GBE from original rom backup, and coreboot config needs to depend on it.

Otherwise, we have another maximized board, where CBFS region should be reviewed in coreboot config, and ifd reviewed one last time to make sure that BIOS region is taking all the space left from ME, considering your ifd is unlocked with ifdtool and the documentation is added into board config to replicate what you have done to be able to provide such ifd. (See x230-maximized blobs dir documentation for example)

[tlaurion]

On X230, the absence of GBE makes the initialization of the ethernet card impossible, since the MAC address is defined under GBE blob. That is why I ask so many questions about it... And to document this board's PR so others can review steps needed to produce a functional port inside of Heads. #700

Thanks for your contribution!

[tlaurion]

@gompa another review round in comments!

[tlaurion]

@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!

[gompa]

@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]

@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.

[gompa]

@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]

doestn match coreboot config line

[gompa]

@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

[tlaurion]

@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.

[tlaurion]

@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.

[MrChromebox]

@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

[MrChromebox]

CONFIG_UART_PCI_ADDR=0
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x80000
CONFIG_DEFAULT_CONSOLE_LOGLEVEL_5=y

these aren't needed

CONFIG_BOARD_GOOGLE_PARROT=y

is duplicated

# CONFIG_DRIVERS_UART_8250IO is not set

should be added

[MrChromebox]

why parrot-common? I'd drop -common

[MrChromebox]

this should be upstreamed to coreboot

[tlaurion]

@gompa ping!

[tlaurion]

@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