Update to coreboot 4.6 release

[osresearch]

Measured boot patches will need to be updated, TPM on x230 needs to be tested (it was broken in HEAD a while ago). https://blogs.coreboot.org/blog/2017/05/08/announcing-coreboot-4-6/

[osresearch]

Looks like the SMM measurement is wrong again; memory region is not zeroed.

[NoiZtril]

Any update on this?

X1 carbon gen1 being supported by 4.6 and really similar to the x230, it seems that that board would be a good candidate for heads.

[Kokokokoka]

Also there is a new gfxinit method with libgfxinit.

[tlaurion]

Any idea on what went wrong?

[cmorche]

I've got a T430S running Coreboot v4.6 currently that is very similar to the X230. I would very much like to assist in porting this. I am currently building a config file, however this is more difficult because I am writing it for an old version of Coreboot... Were there any issues porting Heads to use the latest version?

[tlaurion]

Would it be fixed with https://review.coreboot.org/#/c/21129/

?

[flammit]

I tried to take a stab at this update but ran into problems with the TPM measurements on my x230: PCR0-3 are zeroed. This was after fixing an initial brick which seemed to be due to the Heads rmodule patch (bisected - so didn't find root cause).

I'll debug more to see if I'm missing something obvious and revert.

[flammit]

Sorry for the confusion. I was looking at the PCRS after flashing the x230.flash.rom where CONFIG_MEASURED_BOOT isn't set so of course there weren't any measurements. doh :/

Looks like as long as I drop the Heads rmodule.c patch, the update to coreboot 4.6 boots fine (tested on x230 with Qubes 3.2 and Coreboot 4.6) and the measurement is stable. However based on @osresearch's comments, I'd like to dig into the debug logs to make sure the measurements are covering everything properly because I'm not sure that this addresses what was seen back in May.

@cmorche / @tlaurion - I can push a PR and a branch if there's interest to test before a merge, just let me know which OS you're targeting since the Xen version (4.6 for Qubes 3.2 vs 4.8 for Qubes 4) isn't configurable yet.

[tlaurion]

Would test gladly against Qubes 3.2.

[cmorche]

Glad to hear this!

I'm still working to port the current stable version to my ThinkPad T430S (almost identical to the x230), but once I have that working I'd be happy to test Xen 4.8 for Qubes v4.

[flammit]

Here's the patch I used to update to coreboot 4.6 (on top of my master branch): https://gist.github.com/flammit/d07a9b0f3c5e3c5336a9df684edcfcaf

Here's a branch for Qubes 3.2 / coreboot 4.6: https://github.com/flammit/heads/tree/coreboot-4.6

[flammit]

I'm gonna hold off on submitting a PR for this until #230 is merged since I unfortunately based my last few branches on this (which is my master).

[cmorche]

I just tried it on my T430S (modified the x230 config) and unfortunately it just booted to a black screen, however the fan stays on full blast (unlike past failures where it usually stops after a second).

I'll spend some more time getting the stable release working with my model first I suppose...

[flammit]

FYI - I "debugged" my x230 black screen by removing patches/coreboot-4.6.patch to verify it boots w/o the Heads-related measurement patches, then incrementally adding them back. Note I was removing the entire build/coreboot-4.6/ directory to ensure a proper patch&rebuild (which is a little painful because of the crossgcc build time).

I've got a beaglebone black coming today so hopefully I can do more detailed EHCI debugging.

[tlaurion]

Measurements seem consistent!

[tlaurion]

Was too enthusiast. No they are not consistent. After some time, when the computer is reset or shutdown, I get: "Unable to unseal totp secret" "TOTP code generation failed".

to reproduce:

• mount /boot
• mount -o remount,rw /boot
• rm /boot/kexec*
• umount /boot
• tpm-reset
• (ctrl-alt-del)
• (ctrl-alt-del)
• r (before heads plymouth menu)
• seal-totp (camera shot from google authenticator)

Now i get the right totp, no error from heads. Hit m. Select new to default option with gpg card inserted. That works. On next reboot, totp is right, no error. At that point, if I power off and disconnect the power supply and battery, connect everything back and power on, I get the error.

Same for you?

[tlaurion]

At the moment of entering the tpm password to save new defaults, the totp code shown there is invalid when compared to the one on my phone.

[flammit]

thanks for the feedback @tlaurion - I'll try to repro/debug tonight and over the weekend.

[tlaurion]

You can troubleshoot the tpm with a bbb screwdriver? Will give it a try tonight to see what is happening there. But since the linux kernel takes usb ownership, how can the bbb be used to debug after linux payload as been launched? BBB can be used to debug coreboot early measurements only, right?

[flammit]

No don't think it can troubleshoot the tpm directly.

I think your problems are related to the part of the patch that I dropped to make it boot (in rmodule.c which zeroizes the extra memory), but couldn't debug why it was hanging (hence the BBB). This would be inline with what @osresearch said in May. I also wanted to take a closer look and verify all the other tlcl_measure(...) calls.

[flammit]

Sorry was too enthusiastic as well. The good news is that I can easily repro and confirm that PCR-2 is indeed changing. Will revert when I have a fix.

[flammit]

FYI - I think the two problems I had of "hang on boot" and "PCR-2 drift" stem from CONFIG_RELOCATABLE_RAMSTAGE being set in coreboot 4.6.

With the Heads rmodule.c memset zero patch, ramstage fails and constantly goes back to romstage because I think the module relocation block has been zeroed so no pointers are adjusted to the new base offset.

After removing the patch, the measured memory for the relocated ramstage module can now vary based on the relocated pointers:

Run 1:

Decompressing stage fallback/ramstage @ 0xbff33fc0 (281264 bytes)
TPM: pcr 2 measure bff33fc0 @ 224608: ea225f2e4cf5f583450bcf1a346a892bf8768973
...
Loading module at bff34000 with entry bff34000. filesize: 0x33a50 memsize: 0x44a70
Processing 3252 relocs. Offset value of 0xbfe34000
TPM: pcr 2 measure bff34000 @ 281200: e1909d34bceb638862566e37f9c90a9e0e03a01b

Run 2:

Decompressing stage fallback/ramstage @ 0xbff32fc0 (281264 bytes)
TPM: pcr 2 measure bff32fc0 @ 224608: ea225f2e4cf5f583450bcf1a346a892bf8768973
...
Loading module at bff33000 with entry bff33000. filesize: 0x33a50 memsize: 0x44a70
Processing 3252 relocs. Offset value of 0xbfe33000
TPM: pcr 2 measure bff33000 @ 281200: 889c9af8a071ca97779eebde72caad517efaf394

If only the first PCR measurement from the in memory CBFS module prior to rmodule logic is used, that could fix the changing measurement problem. @osresearch what do you think?

[flammit]

Here's another patch to my master (https://gist.github.com/flammit/787579af9e5f4ee4a169d71a867d7eb6) and another commit for the coreboot-4.6 branch (https://github.com/flammit/heads/tree/coreboot-4.6).

From the logs, you'll see that the relocated module measurements aren't done anymore for the whole ramstage (00100000 @ 281200) or for the SMM modules (00038000 @ 352, c0010000 @ 29568, c0008000 @ 352). The decompressed ramstage is still measured (00100000 @ 210416 in 4.5 and bff32fc0 @ 224608 in 4.6).

Coreboot 4.5:

TPM: pcr 2 measure ff930000 @ 65536: 0faf6b1a77215717f4144a089c5fa4f86669136c
TPM: pcr 2 measure 00100000 @ 210416: 4b3bba52bed674515bd8d97a3a981beb08605b3f
TPM: pcr 2 measure 00100000 @ 281200: f3852f58dc022a0c84145403815072292fd4b70c
TPM: pcr 3 measure 00038000 @ 352: e8b64124f51764f5e093969f691d9aca85a469cd
TPM: pcr 3 measure c0010000 @ 29568: a64f16790f71a889fcf52fcdfa9c7be180da5ed2
TPM: pcr 3 measure c0008000 @ 352: 809618b1dfdbd68b98bb7e24744351013d5fd17b
TPM: pcr 3 measure ff9001d0 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff9001d0 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff9001d0 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff9001d0 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff930000 @ 65536: 0faf6b1a77215717f4144a089c5fa4f86669136c
TPM: pcr 3 measure ff906388 @ 13847: 10f19fc8b6d197d239b7a8f6c39eda91b85efaa2
TPM: pcr 3 measure 00090000 @ 4224: ea07164c72a6e70efa71a1c682920447a821fb2f
TPM: pcr 3 measure 01000000 @ 2670624: 4dd6246f30c1034e816f493875d4f939a19eaf91
TPM: pcr 3 measure 00040000 @ 177: 42b5a23aae79b2f57de55635d5436d1f81713afa
TPM: pcr 3 measure 00091000 @ 27: 7620faf118a35ff942c520cb83dd4990204d8cda
TPM: pcr 3 measure 04000000 @ 3340116: ebd911f4dec3c065bc8957b9844f5425de295f4c

Coreboot 4.6 w/ latest patch:

TPM: pcr 2 measure ff920000 @ 65536: 0faf6b1a77215717f4144a089c5fa4f86669136c
TPM: pcr 2 measure bff32fc0 @ 224608: 9900cf4a0c9db10da742da47e6e06374424574aa
TPM: pcr 3 measure ff917150 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff917150 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff917150 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff917150 @ 22528: c84b356a1d6fc6c0ce7cec808c5ec5179f8e198e
TPM: pcr 3 measure ff920000 @ 65536: 0faf6b1a77215717f4144a089c5fa4f86669136c
TPM: pcr 3 measure ff9476c8 @ 13405: e540f90ff2404e992b6058e8468e76c4435ebdfe
TPM: pcr 3 measure 00090000 @ 4224: 5e82e464b3d13c0e9dd4443716a142d0f80edf03
TPM: pcr 3 measure 01000000 @ 2670624: 4dd6246f30c1034e816f493875d4f939a19eaf91
TPM: pcr 3 measure 00040000 @ 177: 42b5a23aae79b2f57de55635d5436d1f81713afa
TPM: pcr 3 measure 00091000 @ 27: 7620faf118a35ff942c520cb83dd4990204d8cda
TPM: pcr 3 measure 04000000 @ 3355256: 377caeff5840343e9e0346a7e923ca340926e36f

I think this should be okay, but defer to someone more knowledgeable.

Seems to make my x230 happy now. I'll note that after the first reboot, PCR1-3 all changed. PCR2/3 change due to MRC cache, but I'm not sure why PCR1/romstage would've changed (though this might have been the case in coreboot 4.5 as well).

@tlaurion let me know if you encounter any issues.

[tlaurion]

Measurements are consistent! Why was the ramstage measured before and after decompression in 4.5?

[flammit]

There's an old issue (#15 "Region at 0x100000 is measured twice"), so I believe it was probably unintentional but defer to @osresearch on whether the new measurement scheme is sufficient.

I believe it's still actually measuring the full decompressed ramstage but there's extra memory allocated to the program to support a bss block larger than reloc (which will be zeroed as part of the relocation anyway).

[flammit]

@osresearch looks like you're quite busy with the NERF updates, but any chance that PRs #230 then #210 can be merged so that I can add a new PR for this coreboot 4.6 update? I have a branch at https://github.com/flammit/heads/tree/coreboot-4.6 for this.

[Kokokokoka]

Maybe it's better to skip 4.6 directly to the 4.7 one, as it will be ready this month?