KGPE-D16 Coreboot 4.11 + Measured Boot #867
Conversation
|
I will use your branch and push it on my own github so that the built is made, since my github heads is followed by CircleCI which trigger builds for defined boards under .circleci/config.yml I will do edit .circleci/config.yml for it to only build kgpe-d16 boards touched by your branch. |
|
@Tonux599 actually, decided to start by just replicating your branch to trigger a build. (Rebasing resulted iun chaos) |
…uilds. PoC build for linuxboot#867
|
@Tonux599 Build resulting of merge conflict resolution is happening here: https://app.circleci.com/pipelines/github/tlaurion/heads/536/workflows/823f5132-5586-40d1-be03-3fbd55e01e9e/jobs/580 From branch https://github.com/tlaurion/heads/tree/tonux_kgpe-d16_411_measured-boot_rebased |
|
@tlaurion so |
…uilds. PoC build for linuxboot#867
…uilds. PoC build for linuxboot#867
|
Success here. Will bring this PR on par with that. Edit: |
Tonux599
force-pushed
the
kgpe-d16_411_measured-boot
branch
from
d548ef9
to
c406217
Compare
…uilds. PoC build for linuxboot#867
…uilds. PoC build for linuxboot#867
|
@Tonux599 https://app.circleci.com/pipelines/github/tlaurion/heads/541/workflows/9d19e4e0-a6ab-4d68-bfa1-f47d61b9b760/jobs/588 has passed. The question here is to know if the microcodes are applied by QubesOS early enough / if the system requires them for some CPUs or not at this point. You can cherry pick or rebase force push https://github.com/tlaurion/heads/tree/tonux_kgpe-d16_411_measured-boot_rebased on top of here and that would replace #795 :) or I can push my branch over #795 with your commits if build is successful. I think we should remove microcodes, but I haven't tested the builds myself yet. |
|
@tlaurion I think we may have made the same changes in each of our branch as this PR now builds as is but I can still force push yours to this if you desire. Let me know :) Regarding the microcode, gimme a few days as I'll see if I can fix that error. My concern being that if microcode is not measured and not included in the CBFS, an attacker could implement malicious microcode without the end user being aware. |
|
Todo:
|
@Tonux599 Well, microcode injection still requires AMD signatures on binaries pushed to CPU so I am not sure that is a real risk. My recommendation was to disable microcode inclusion in ROM. But if you think you can fix this, no prob. My intuition confirms your doubts that microcode measurements are not possible at the stage TPM is initialized. AFAIK microcode is being injected prior of the romstage, while kgpe-d16 is implementing measurements in romstage in 4.11. So that might not be possible without implementing TPM measurements into bootblock, which from past discussions, doesn't seem possible for that board in 4.11 unless a lot of 4.12 patches are brought back, but I have not investigated this. https://github.com/tlaurion/heads/tree/tonux_kgpe-d16_411_measured-boot_rebased is just rebased on master with a more clean CircleCI config, that could be merged as is, since all baords were built successfully, while cache is still being made and uploaded as we speak (with same signature that will be reused for all modules/* and patches/* being the same). |
Tonux599
force-pushed
the
kgpe-d16_411_measured-boot
branch
from
c406217
to
0782f77
Compare
boards/kgpe-d16_server-whiptail/kgpe-d16_server-whiptail.config
Outdated
Show resolved
Hide resolved
|
@MrChromebox : what is the impact of those coreboot 4.11 patches on the librem_l1um ? |
@Tonux599
Is shown twice? |
@miczyg1 @pietrushnic any idea on modyfying https://github.com/osresearch/heads/blob/0782f77b9b6f93168decb95f7f4bb09453482272/patches/coreboot-4.11/0020-kgpe-d16_measured-boot-support.patch and https://github.com/osresearch/heads/blob/0782f77b9b6f93168decb95f7f4bb09453482272/patches/coreboot-4.11/0021-kgpe-d16_c-environment_bootblock.patch so that TPM is initialized early enough to measure microcode and to fix TPM being initialized twice? |
the only one which affects anything outside of the KGPE-D16 itself is the C environment patch, and that shouldn't be problematic. I'd want to test and verify to be sure though. More generally though, feel like this 53-commit patch set could be squashed to ~5 commits and make reviewing a bit easier |
@tlaurion romstage is called three times when the board is booted, with the first two times a soft reset is called. It's likely that the romstage doesn't reach the TPM initialisation on its first iteration and does so on the second and third. This behaviour has been persistent throughout my work on this board. |
If CBFS is modified then it doesn't matter if you use legacy reset vector or CBFS API or hardcoded addresses. The measured code will not be the one which was booted in all cases... Using hardcoded 0xFFFFF800 isn't better either. Somebody can place a modified bootblock there too. The CBFS API will return this address if nothing was modified. How do you trust the CBFS API to locate next stages then? How do you trust the romstage or ramstage that is executed next after bootblock? If the flash is not protected in any way (either ACM or WP pin) what is the trust anchor here? Or what are the measurements for? If somebody replaces this bootblock, it should be reflected by the measurements. Maybe I am biased with how coreboot is developed: "if some functionality in the coreboot exists, use it instead of hardcoding or reimplementing the wheel". @Tonux599 I am sorry if my advice was bad. |
|
For example one may modify just a single letter in CBFS file header, for example file name |
@miczyg1 There is no need to apologise as I hold no difference in value of your advice or @osresearch's advice. At this stage I'm merely nothing more than someone who has some free time to attempt to bring a board that they own into support with heads. I will, however, make adjustments to my contributions (unless I have a moral objection) in line with projects maintainers wishes (which is a little unclear at the moment, clarification on @tlaurion's and @osresearch's role in the project could be laid out in a But back to the subject, I would encourage @miczyg1, @osresearch and really anyone whom have a good understanding coreboot to continue arguing, at which point I would expect maintainers to weigh each side of the argument and reach a decision. I would then implement that. |
|
@miczyg1 @osresearch : I'm kinda confused right now.
Consequently PCRs measurements for each PCRs are:
Any problem/improvements that can happen here if there is no ACM? |
These references are not really related to the discussion. The mentioned mechanisms are heads specific and it is all about heads how they will be handled. They do not have any particular impact on the coreboot stage localization. If I am not mistaken the CBFS API responsible for locating coreboot stage during boot are intact. So for me it is pointless to hardcode the bootblock address and size if the CBFS API can locate it and return the size. The security threat does not change by using CBFS API here, if someone modifies the flash on the fly, it doesn't matter what method was used (hardcoding or CBFS API). The same CBFS API is used to locate coreboot stages during boot, someone may put a fake/malicious ramstage or other
No particular comments with that. It looks good. |
|
Bootblock is not protected by any means more to that IIRC it measures itself. Bootblock can easily lie about itself and this is an attack vector.
@osresearch if I understand the only way to do that is somehow trick SPI reading (spispy?), but do we really have to use such a sophisticated mechanism when we have no S-CRTM? Also, I think @miczyg1 got it right and it doesn't matter if we hardcode or use CBFS API if this CBFS API is the problem we should distrust it in all cases not only in bootblock. Of course, hardcoding all addresses will eventually cause maintenance issues that's why if there is no difference in threat model we should use a more convenient mechanism. |
|
So just to note, I've been using kgpe-d16_workstation for about a week now with an nvidia card and Qubes 4.0 and can confirm that all appears stable and heads specific function (i.e. adding PGP keys to flash) work without error. @osresearch I'm inclined to keep @miczyg1's implementation of locating bootblock unless you have anything further to argue? Your input on what @miczyg1 and @pietrushnic have said would really be appreciated. |
Tonux599
force-pushed
the
kgpe-d16_411_measured-boot
branch
from
c430da7
to
edd2d5a
Compare
|
Force push due to email change (email updated on both GitHub and PGP key). HEAD is verified but commits before appear unverified. When clean-up + squash take place all commits will be signed and verified correctly. |
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
Tonux599
force-pushed
the
kgpe-d16_411_measured-boot
branch
from
edd2d5a
to
d9f9be1
Compare
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
Bring patches/coreboot-4.11 on par with master Removed patches/coreboot-4.11/0020-kgpe-d16-vboot.patch Removed Vboot options from KGPE-D16 coreboot configs Enabled TPM in kgpe-d16 board configs Enabled measured boot in kgpe-d16 coreboot configs. Added support for video cards that require nouveau, radeon and amdgpu drivers in linux-kgpe-d16_workstation.config `nouveau.config=NvForcePost=1` to be added to kexec'd kernels for better Nvidia card support.
…t defined, describe better board configs applications
cp config/linux.. ./build/linux*/.config cd build/linux* make savedefconfig cp defconfig ../../config/linux.. Resulting in only linux-kgpe-d16_workstation.config being updated. For KGPE-D16 workstation boards: Remove `console=tty0` from `CONFIG_BOOT_KERNEL_ADD` as was blocking Qubes graphical installer (CLI installer was launched). Comment out `export CONFIG_BOOT_KERNEL_REMOVE="plymouth.ignore-serial-consoles"` to provide a more desktop like experience. Removed 0001-cpu-x86-smm-Use-PRIxPTR-to-print-uintptr_t.patch as already exists as 0000-cpu-x86-smm-Use-PRIxPTR-to-print-uintptr_t.patch Added 0020-kgpe-d16_measured-boot-support.patch for coreboot 4.11 Fix TPM errors when microcode is measured by initialising TPM earlier and loading the microcode later. Thanks to Michał Żygowski <miczyg1> for condition suggestion: `if (CONFIG(MEASURED_BOOT) && CONFIG(LPC_TPM) && boot_cpu())` Locate bootblock location and size with CBFS API. Credit to: Michał Żygowski <miczyg1>
Tonux599
force-pushed
the
kgpe-d16_411_measured-boot
branch
from
d9f9be1
to
572f5b3
Compare
Tonux599
changed the title
|
Rebased. Ready imo @tlaurion |
|
I can confirm it works with CONFIG_TPM=n. Excellent job @Tonux599 |
Edit (tlaurion): TPM used by @Tonux599 : Asus 90-C1B0AU-00XBN0VZ
This is based upon #795 (credit to @tlaurion) but focuses on measured boot without vboot.
I would appreciate feedback from the community, notably that
./patches/coreboot-4.11/0020-kgpe-d16_measured-boot-support.patchis implemented correctly.Also note that this error occurs when microcode is included in the CBFS:
However when microcode is removed such as:
The above error does not occur:
I think this is because the TPM is not initialised early enough but will test more soon.