Enable vboot on Lenovo devices for measured boot #709
Conversation
|
A quick recap on the status of this PR. From commit logs, general concerns in bold
|
|
Please comment inline what should be fixed. Marking sentences bold doesn't help anybody. The first commit could be postponed until the next coreboot release, which will likely be released in two weeks. |
|
Testing. |
|
@PatrickRudolph : Some notes. |
|
@PatrickRudolph : Debian-10 output: |
|
Oh yes good point. That script requires patches on top coreboot 4.11 that are merged into the next release. |
|
@PatrickRudolph : What interests us from minimal_me (standard vboot-* platforms) may be the usage and adaptation of:
|
|
It might be possible to generate the GBE and fill it with a random MAC. |
|
@PatrickRudolph : I've tested #721. Results there. Let me know if something newer needs to be tested or if same results would be expected from PCRs. |
There was a problem hiding this comment.
Oh yes good point. That script requires patches on top coreboot 4.11 that are merged into the next release.
@PatrickRudolph 4.12 having been released and #721 being community work in parallel, I wait for your input to when you are ready for me to test this PR.
boards/t420/t420.config
Outdated
| @@ -1,7 +1,7 @@ | |||
| # Configuration for a T420 running Qubes and other OS, T420 is identical to X230 on the Linux Side of things. | |||
| export CONFIG_COREBOOT=y | |||
| CONFIG_COREBOOT_CONFIG=config/coreboot-t420.config | |||
| CONFIG_LINUX_CONFIG=config/linux-x230.config | |||
| CONFIG_LINUX_CONFIG=config/linux-thinkpad.config | |||
There was a problem hiding this comment.
@PatrickRudolph We might want to name this xx30 instead of thinkpad, since base linux configuration might be different for xx20 and xx30 boards
There was a problem hiding this comment.
@PatrickRudolph I'm thinking of the RICOH and REALTEK SDCARD MMC reader for the only example I know for the x230, which i'm not even aware if used across xx30 boards. Your insights here would be welcome. Might or might not be a concern.
My point here is that the xx20 containing less space then xx30, it might not be advisable to share a linux config across boards, since xx20 might need even more tuning of config where the xx30 boards might not.
modules/coreboot
Outdated
| #coreboot_repo := https://review.coreboot.org/coreboot.git | ||
| coreboot_version := 4.11 |
There was a problem hiding this comment.
@PatrickRudolph My concern here is that oher boards (kgpe-d16) will probably stay on 4.8.1 for a while. I think it would be advisable to probably duplicate coreboot module and have boards specify which coreboot version they are based on, even though this would require more tracking of versions in the future.
Changing coreboot for all boards at once might bring undesired results for untested boards, while changing them one by one after testing on a community based would seem more advisable.
|
@MrChromebox @osresearch Heads and coreboot don't use the same PCRs. |
|
@tlaurion I'm unclear what you're proposing. Also, coreboot's use of the PCRs will vary depending on if vboot is used or not. |
|
OK let me clarify this and Patrick should clarify additionally. 9elements work here is to bring VBOOT+measured boot to platforms missing it on coreboot mainline (xx30 and xx20). Doing so, heads and coreboot are using different PCRs for measured boot implementation. Two options here, we have coreboot patched so that measuring scheme of heads don't change. Or we change heads measuring scheme to match coreboot's VBOOT+measured boot. We have to take a decision. |
|
@MrChromebox @PatrickRudolph we need to take a decision for things to move on and development to go ahead. To minimize heads change, it seems that coreboot should be patched. To facilitate maintainership, it seems that Heads should be modified. Coreboot 4.12 includes measured boot without vboot. VBOOT requires space that is scarce and doesnt seem fit for Heads. What do we do? |
|
@tlaurion to clarify, coreboot 4.12 provides the option to use measured boot with or without vboot. so we can support both versions if desired and space available. Question is, is the PCR measurement performed by coreboot 4.12 less secure/optimal than that done by Heads currently? Or just different? |
|
@MrChromebox this is answered here and exposed there.
Short answer is: different. Condensate of #721 (comment) (please read): @MrChromebox : I have not played with MeasuredBoot without VBOOT, nor can find proper documentation from coreboot website, which was the goal of funding the work at the first place #540 which led to #605 which resulted in this PR for the moment, which doesn't fill the bill and now stalls, see next note.
Which links to #307 and still unresolved problems for distribution. @PatrickRudolph? What are the next steps? What do you think of Heads measuring scheme as opposed to coreboot without VBOOT? |
|
@PatrickRudolph @MrChromebox : @osresearch says that we should change Heads to match coreboot measuring scheme:
@PatrickRudolph @pietrushnic this one is for yous:
@MrChromebox : I understand that most of the boards you support will go the VBOOT+measureboot, while xx30 and xx20 boards will go the measured boot path without VBOOT for lack of space. @PatrickRudolph : where can we see the measured boot without Vboot measuring scheme? Is it different then VBOOT+measured boot? |
|
@tlaurion For Boot Guard, besides the IBB, the PCR0 is extended with Boot Guard configuration, ACM SVN and signature, manifests signatures. And yes, that is a conflict with vboot's PCR0. AFAIK boot extends boot mode in PCR0 only. |
|
@MrChromebox @PatrickRudolph : so how do we deal with PCR0 and adapt heads to coreboot measuring scheme following precedent comment? |
|
@MrChromebox @PatrickRudolph discussions on implementation continues here #721 (comment) Should we close this PR? |
Documentation changes linked to PCR usage in coreboot 4.8.1 and newer versions, to be applied at the same time as linuxboot/heads#793 is merged. Linked to VBOOT+Measured boot/Measured boot changes applied directly in coreboot so that we have a common base prior of going linuxboot/heads#709 and linuxboot/heads#721 @PatrickRudolph comments welcome
…#42) * Update Keys.md Documentation changes linked to PCR usage in coreboot 4.8.1 and newer versions, to be applied at the same time as linuxboot/heads#793 is merged. Linked to VBOOT+Measured boot/Measured boot changes applied directly in coreboot so that we have a common base prior of going linuxboot/heads#709 and linuxboot/heads#721 @PatrickRudolph comments welcome * Update Keys.md Removed comment about MRC needing to be measured into different PCR since coreboot is merging them all under PCR2 in newer VBOOT+measured boot/measuredboot Ref:https://doc.coreboot.org/security/vboot/measured_boot.html
|
28d3b7c being merged #721 #709 are next. |
|
@tlaurion #721 is ready to go, but #709 definitely isn't. Either needs to be rebased on 4.12, or rebased to add support for coreboot 4.11 rather than replacing. I'd strongly advocate for the former, since I'm not sure there's any value to adding support for 4.11 at this time (we may want to for other boards than can't be updated to 4.12, eg KGPE-D16) |
|
@PatrickRudolph this can be resumed since #721 was merged. |
|
@PatrickRudolph Any news? |
* Add vboot support to supported Lenovo boards * Didn't add config that wouldn't build (non ME stripped versions) Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
PatrickRudolph
force-pushed
the
vboot
branch
from
8824eba
to
60275d2
Compare
|
Any comments on the new commits? |
|
@PatrickRudolph Will look into it tomorrow. Thanks! (Didn't see since not tagged, sorry for the delay) |
|
@PatrickRudolph build successfull (x230-vboot and t430-vboot): https://app.circleci.com/pipelines/github/tlaurion/heads/393/workflows/1c587111-101b-418b-9918-413c5addc255/jobs/422 (cannot build from CI t420 and x220 since blobs) Requires the following change (would be nice that it is merged into this PR so its self-contained):
Artifacts: I will test x230-vboot rom in a bit, cannot test any other platforms. |
…1 patch brought up per linuxboot#709
|
flashed x230-vboot.rom over #703 externally flashed x230 with Would have thought that would work, since IFD is maximized for BIOS region while ME is minimized there, but I guess VBOOT should be flashed some other way. Is something special expected from x230-flash.rom, or should x230-flash-vboot exists? Is IFD supposed to be modified in some way prior of flashing? |
That brick may be related to this response here in which vboot is not functional when using a read-only flashmap. I have replied to the thread to see if the behaviour that is described by Julius applies to coreboot 4.12 as well as 4.11 and will update here when I know. EDIT: Note the reply here in particularly:
As such, it appears that read-only flashmaps (which is what this PR uses) won't work with vboot and support has yet to be implemented. A workaround may be to use a large RW section and a small RO section in the .fmd 's and to exclude the payload from being written to the RO section. I'll be working on that theory in regards to the KGPE-D16 and coreboot 4.11. Julius also notes:
If this is sufficient to the goals of Heads this would appear to work also. |
…1 patch brought up per linuxboot#709
…1 patch brought up per linuxboot#709
|
@PatrickRudolph so this is not functional as of now without further instructions. So still no coreboot 4.12 for xx20 nor xx30 with Heads payload. |
|
@tlaurion worth noting that that error is the same as the one we were getting when trying to make KGPE-D16 + coreboot 4.11 + vboot. |
|
@Tonux599 : that was fixed in https://circleci.com/api/v1.1/project/github/tlaurion/heads/620/output/139/0?file=true&allocation-id=5f9c17bd45255007fb8bb449-0-build%2F2737844C with tlaurion@7afdc23 Unfortunately, it comes with another error, saying that musl-cross-make is not providing |
Here is how i compiled heads with coreboot 4.12 for t430.
from there at least it compiled , but i faced permament black screen while the board stays powered on as opposed to #897 I think that heads should not rely on muslc to compile coreboot but use the built in coreboot toolchain, however i m just a noobs in this area :) |
|
@zaolin @PatrickRudolph that was supposed to be paid by NlNet when functional and mergeable. |
Changing CONFIG_USB_BOOT_DEV to sdc1, adding back CONFIG_BOOT_STATIC_IP to 192.168.2.3, adding dual console to OpenBMC and tty0 in attempt to have QubesOS graphic installer which complains with no networking when attempting to start VNC Adding dual console to OpenBmc and tty0 putting kgpe-d16-coreboot.conf in defconfig format NO_HZ wasn't included in kernel config. Adding it. Wasn't able to have both console firing up QubesOS gui installer, complaining about hvc1 console errors. Splitting up Workstation and server config. This one works for Worstation Removing serial configuration and static IP stuff since we have a workstation here. Seperate Workstation and Server board configurations until dual console truely works through QubesOS gui installation. kgpe-d16 board config removed until then. Placing files in good directories Corrrect flashrom options for kgpe-d16 server and workstation boards kgpe-d16 linux: NO_HZ_IDLE instead of NO_HZ kgpe-d16: seperate board for workstation to be AST and gui-init based, while kgpe-d16-> kgpe-d16_server kgpe-d16_server: boots, shows ASpeed text on VGA, controllable through BMC via SSH. kgpe-d16_workstation on ASpeed console. WIP. (Includes CIs configs to build server and workstation) kgpe-d16_workstation in defconfig format kgpe-d16 boards: pass from GPG to GPG2 board definitions kgpe-d16_workstation : Adding Cairo and FbWhpitail in board config for gui-init to work in FB mode kgpe-d16: removing plymouth.ignore-serial-consoles to fix server terminal output kgpe-d16: bring par with staging branch https://gitlab.com/tlaurion/heads/commits/kgpe-d16_staging kgpe-d16 : expressively export CONFIG_TPM=n kgpe-d16_wokstation gui-init variables were missing kgpe-d16 boards: add CONFIG_LINUX_USB_COMPANION_CONTROLLER so that usb is recognized linux-kgpe-d16*: add support for Pike kgpe-d16_workstation-usb_keyboard board support addition kgpe-d16_server-whiptail: Add board and dependencies to have gui-init in whiptail (console mode, not FbWhiptail based GitlabCI: kgpe-d16 fixes and upstream merge of change kgpe-d16* board: add statement to fixate coreboot version to 4.8.1 for the moment kgpe-d16: add missing config/linux-kgpe-d16_server-whiptail.config file KGPE-D16: community work migration to coreboot 4.11 to fix issue linuxboot#740 KGPE-D16 boards: Adding VBOOT+measured boot, musl-cross patch and 4.11 patch brought up per linuxboot#709 kgpe-d16* boards: add VBOOT Kconfig patch per @miczyg1 recommendation under linuxboot#795 (comment) KGPE-D16* coreboot configs: Add S3NV as a Runtime data whitelist (so that it is not measured at term) per @miczyg1 recommendation under linuxboot#795 (comment) kgpe-d16 coreboot 4.11: add https://review.coreboot.org/c/coreboot/+/36908 patch kgpe-d16 boards: add Linux kernel version where missing. CircleCI: Add debug output on fail for kgpe-d16 board builds to bring par with upstream after rebasing on master coreboot module: typo correction (tabs vs spaces) CircleCI: trying to address "g++: fatal error: Killed signal terminated program cc1plus." happening under coreboot 4.11 and coreboot 4.12 builds CircleCI: remove past addition to test recommendation from CircleCI: "resource_class: large" CircleCi: Ok.... lets output dmesg content prior of other logs.... I'm out of ideas. Next step, ask CircleCI for support At this stage: - job's "make --load" is supposed to guarantee that the number of thread doesn't exhaust pass of a load of 2 (medium, free class, CircleCI has 32 cores so possibility of a load of 32) - "--max_old_space_size=4096" in CircleCI environement is supposed to limit memory consumption to 4096Mb of memory, the max of a medium class free tier CircleCI node CircleCI: remove verbose build (no more V=1), in case of failed build, find all logs modified in last minute and output each of them on console. coreboot module: implement load average respect inside of problematic CI build for coreboot 4.11+ being killed in the action (32 cores with 4Gb ram get gcc OOM) coreboot module: replace nproc by number of Gb actually available as number of CPUs, since each thread is expected to have 1Gb of ram. CircleCI & coreboot config: fix merge conflict rebasing on master coreboot 4.11 kgpe-d16 vboot patches addendum, credits goes to @Tonux599 Fix merge conflicts and make sure all boards are inside of CircleCI builds. PoC build for linuxboot#867
Changing CONFIG_USB_BOOT_DEV to sdc1, adding back CONFIG_BOOT_STATIC_IP to 192.168.2.3, adding dual console to OpenBMC and tty0 in attempt to have QubesOS graphic installer which complains with no networking when attempting to start VNC Adding dual console to OpenBmc and tty0 putting kgpe-d16-coreboot.conf in defconfig format NO_HZ wasn't included in kernel config. Adding it. Wasn't able to have both console firing up QubesOS gui installer, complaining about hvc1 console errors. Splitting up Workstation and server config. This one works for Worstation Removing serial configuration and static IP stuff since we have a workstation here. Seperate Workstation and Server board configurations until dual console truely works through QubesOS gui installation. kgpe-d16 board config removed until then. Placing files in good directories Corrrect flashrom options for kgpe-d16 server and workstation boards kgpe-d16 linux: NO_HZ_IDLE instead of NO_HZ kgpe-d16: seperate board for workstation to be AST and gui-init based, while kgpe-d16-> kgpe-d16_server kgpe-d16_server: boots, shows ASpeed text on VGA, controllable through BMC via SSH. kgpe-d16_workstation on ASpeed console. WIP. (Includes CIs configs to build server and workstation) kgpe-d16_workstation in defconfig format kgpe-d16 boards: pass from GPG to GPG2 board definitions kgpe-d16_workstation : Adding Cairo and FbWhpitail in board config for gui-init to work in FB mode kgpe-d16: removing plymouth.ignore-serial-consoles to fix server terminal output kgpe-d16: bring par with staging branch https://gitlab.com/tlaurion/heads/commits/kgpe-d16_staging kgpe-d16 : expressively export CONFIG_TPM=n kgpe-d16_wokstation gui-init variables were missing kgpe-d16 boards: add CONFIG_LINUX_USB_COMPANION_CONTROLLER so that usb is recognized linux-kgpe-d16*: add support for Pike kgpe-d16_workstation-usb_keyboard board support addition kgpe-d16_server-whiptail: Add board and dependencies to have gui-init in whiptail (console mode, not FbWhiptail based GitlabCI: kgpe-d16 fixes and upstream merge of change kgpe-d16* board: add statement to fixate coreboot version to 4.8.1 for the moment kgpe-d16: add missing config/linux-kgpe-d16_server-whiptail.config file KGPE-D16: community work migration to coreboot 4.11 to fix issue linuxboot#740 KGPE-D16 boards: Adding VBOOT+measured boot, musl-cross patch and 4.11 patch brought up per linuxboot#709 kgpe-d16* boards: add VBOOT Kconfig patch per @miczyg1 recommendation under linuxboot#795 (comment) KGPE-D16* coreboot configs: Add S3NV as a Runtime data whitelist (so that it is not measured at term) per @miczyg1 recommendation under linuxboot#795 (comment) kgpe-d16 coreboot 4.11: add https://review.coreboot.org/c/coreboot/+/36908 patch kgpe-d16 boards: add Linux kernel version where missing. CircleCI: Add debug output on fail for kgpe-d16 board builds to bring par with upstream after rebasing on master coreboot module: typo correction (tabs vs spaces) CircleCI: trying to address "g++: fatal error: Killed signal terminated program cc1plus." happening under coreboot 4.11 and coreboot 4.12 builds CircleCI: remove past addition to test recommendation from CircleCI: "resource_class: large" CircleCi: Ok.... lets output dmesg content prior of other logs.... I'm out of ideas. Next step, ask CircleCI for support At this stage: - job's "make --load" is supposed to guarantee that the number of thread doesn't exhaust pass of a load of 2 (medium, free class, CircleCI has 32 cores so possibility of a load of 32) - "--max_old_space_size=4096" in CircleCI environement is supposed to limit memory consumption to 4096Mb of memory, the max of a medium class free tier CircleCI node CircleCI: remove verbose build (no more V=1), in case of failed build, find all logs modified in last minute and output each of them on console. coreboot module: implement load average respect inside of problematic CI build for coreboot 4.11+ being killed in the action (32 cores with 4Gb ram get gcc OOM) coreboot module: replace nproc by number of Gb actually available as number of CPUs, since each thread is expected to have 1Gb of ram. CircleCI & coreboot config: fix merge conflict rebasing on master coreboot 4.11 kgpe-d16 vboot patches addendum, credits goes to @Tonux599 Fix merge conflicts and make sure all boards are inside of CircleCI builds. PoC build for linuxboot#867
No description provided.