-
-
Notifications
You must be signed in to change notification settings - Fork 185
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
t420-maximized boards: build against coreboot 4.13 #998
Conversation
@SebastianMcMillan @alexmaloteaux : measured boot output here: |
@SebastianMcMillan @alexmaloteaux since I do not own the board, I would need at least one confirmation prior of merging and moving CI config for that board to depend on 4.13 material on CircleCI. |
CircleCI build happening here: https://app.circleci.com/pipelines/github/tlaurion/heads/732/workflows/812c5598-47ca-49e1-9819-6dd2f985d633 Note: CircleCI config didn't have to be changed, since t420 builds (and all others) depend on librem_mini build cache, which is coreboot 4.13. Artifacts will be available there in like 8 hours (caches get deleted after 30 days of uselessness [not used by another build]) |
CircleCI builds can be seen here: Build artifacts (roms) resulting of this PR can be downloaded here: As current board config, only the full rom is created. Will need to fix that.... |
@akfhasodh have you tested this under #999 ? |
@akfhasodh Is that what was tested under #1004 ? Or master over coreboot 4.8.1? |
@akfhasodh can I add you under #692 for the t420 board? Will then edit the post with links to fully internally flashable rom from CircleCI. EDIT: as stated #1004 (comment), this is desired change for a while. Initial Heads project introduced measured boot on earlier coreboot. Later coreboot version introduced measuredboot on top of verified boot (4.11 I think) where coreboot 4.13 offeres measured boot without verified boot, which permits to drop initial patchset referred in OP, where most of the patches that were needed to be applied on top of coreboot were merged upstream since then, resulting in Heads becoming more and more a coreboot payload, without being patches to coreboot+ linux payload, as can be witnessed when comparing the patches directories of coreboot 4.8.1 vs 4.13. Measurements of the firmware are now more visible thanks to upstreamed effort. |
@tlaurion yes |
@akfhasodh a build occured for the same coomit id (3e13af1) 29 days ago for which artifacts exists: The actual build "should" result in the same hashes.txt file output since from same CI. EDIT: In all case, it seems that no rom will be reproducible even on the same host since busybox includes timestamps of its build. |
@tlaurion The issue TOTP/HOTP inconsistency issue still persists on the 4.13 rom. Maybe its an issue with my hardware itself? |
What measurement change between boots? |
@akfhasodh: Can you please:
Going into the recovery console is invalidating TOTP unsealing by modifying PCR4. |
Reviewed tested x230-hotp-maximized board config and coreboot changes which didn't add anything special compared to the t420-hotp-maximized board and coreboot config changes. Building here and will retest cbmem and other notes to test my own procedures before asking you to redo. Build is happening here, reusing cache from yesterday build: https://app.circleci.com/pipelines/github/tlaurion/heads/739/workflows/05a5c7c0-8718-4497-99c6-1d63f385cb15/jobs/1159 |
@akfhasodh running I would love to see those when it fails, and when it succeeds on coreboot 4.13 t420-hotp-maximized rom |
@tlaurion Turns out the instability was only something I would experience at the beginning, as all my subsequent boots for the past two days have had successful TOTP/HOTP unseals. If I come across the issue again, I will definitely send the differences in cbmem. |
@tlaurion It started again, and it got worse, After I attempted updating qubes dom0 (and failed), I decided to reboot. Upon the reboot I was met with the same issue of inconsistent unseals. But, once I got a proper unseal, it showed a red screen with the TOTP code displayed, and "HOTP: Invalid code". Up until the failed update things were working fine, unfortunately, I forgot to save the TOTP verification to my phones authenticator, is it possible for heads to have been tampered with without physical access? |
@akfhasodh do you have before/after PCR-2 measurements? It would be useful to have reports from other t420 owners here.
Highly doubtful, while still possible. But highly improbable (iomem=relaxed comment there):
|
@tlaurion |
@akfhasodh payload measurements are different |
@tlaurion What does this mean? |
Are those measurements stable across reboots? There was issue created in the past when CBFS regions mismatched available/used space for measured CBFS regions. One hypothesis here would be that coreboot measurements of the region mismatches reality. Coreboot 4.13 uses TCPA logs to output the TPM measurements into cbmem. I would recommend reflashing internally, resetting TPM, resealing TOTP/HOTP, and taking a screenshot of cbmem when it works. And then retaking a snapshot when it doesn't. There is a larger PR trying to bring Heads based on coreboot 4.13 altogether. The T420 and x220 use the same defined CBFS regions. I would need other board owners output and bug replication to know if there is an issue for xx20 boards and CBFS region. The payload measurements should not change in time. So something is weird here and needs to be diagnosed. Using CI builds would be recommended to have exactly the same hashes: |
Superseded by #1015 |
Bump Coreboot to version 4.13 and enable measured boot. This obviates the need for coreboot 4.8.1 0030-sandybridge.patch
Tested and verified here.
Would be nice to get confirmation from other board owners. Tagging @SebastianMcMillan @alexmaloteaux