WIP xx30/Haswell+ TXT support, IBB CPU anchored RoT through ACM blobs? #1172
Conversation
|
There is an issue with https://tls.mbed.org, so builds are failing for the moment.
Edit : Will do PR to point to https://github.com/ARMmbed/mbedtls/archive/mbedtls-2.4.2.tar.gz instead, problem still not resolved 7 hours later.... Great resource, repology BTW: https://repology.org/project/mbedtls/information |
|
Seems like the required tools were not merged inside of coreboot from this discussion https://www.mail-archive.com/coreboot@coreboot.org/msg55950.html More specifically:
Where converged security suite by 9elements require the work to be done externally on produced coreboot ROM, cbnt option not being avail and where it is, it doesn't permit do do what is needed here. The goal here would be to simply have bootblock in IBB at build time... |
|
Seems like this is what I have to chew on https://9esec.io/blog/first-open-source-drtm-implementation/ |
|
Important update: Will rebase and rename board to be happened with txt instead of ACM. |
Not required. This is optional if one wants to define some custom policies and deny booting an untrusted OS for example. The advantage of adding a policy to CBFS is that you not need to add it from an external storage, i.e. hard drive, like tboot does.
On Sandy/Ivy there is no concept of TXT IBB yet. And so it is not even measured by the ACM during reset. One of the lines says it: A good comparison of logs with Broadwell for example should reveal these differences. |
|
One does not need any manifestation unless Boot Guard is enabled or the machine is at least 10th gen Intel Core CPU (which uses CBnT) |
|
A quick good read is https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html I think |
|
@miczyg1 I assume this is related with project charter for TrenchBoot as Qubes OS AEM? Can we link issues your created here? |
tlaurion
force-pushed
the
txt_x230-hotp-maximized_coreboot_417
branch
2 times, most recently
from
f3157a0
to
56665b5
Compare
|
Rebased on master. |
tlaurion
force-pushed
the
txt_x230-hotp-maximized_coreboot_417
branch
from
56665b5
to
c703b05
Compare
…can't. Broadwell+ can) - Update coreboot target to that it includes coreboot 4.17 - Addition of blobs/xx30/download_extract_acm.sh - Downloads SINIT ACM blob from an archive.org copy of the archive - Downloads Latest BIOS from Lenovo and extracts the ACM BIOS from there - Add a x230-hotp-maximized-acm board config based on coreboot 4.17 - coreboot config includes SINIT and ACM blobs - CircleCI modifications - Add unzip in apt packages requirements - Added a step into CircleCI which calls blobs/xx30/download_extract_acm.sh to have blobs - Add x230-hotp-maximized-ac builds Todos: - txt_bios_policy.bin not present under CBFS (Not required up until Intel gen 10 for Bootguard) - IBB not existing concept, so cannot include bootblock (goal of this inclusion if ACM blobs were desired/tolerated) This is building block for TXT (DRTM) under Heads.
tlaurion
force-pushed
the
txt_x230-hotp-maximized_coreboot_417
branch
from
c703b05
to
df4bcbc
Compare
|
To be considered under #1282 where ACM + Sinit blobs can enable RoT in CPU! |
|
Discussion happening under https://forum.qubes-os.org/t/trenchboot-anti-evil-maid-for-qubes-os/16559/10 For D-RTM enablement and QubesOS AEM support next steps |
- As of now, includes download and extraction scripts under blobs/xx30/download_extract_acm.sh - Adds x230-hotp-maximized-acm and x230-maximized-acm boards - Based on top of both linuxboot#1312 and linuxboot#1172 (coreboot 4.19 based) Next: attempt https://matrix.to/#/!WHWPvnIGPhGGtUFucJ:matrix.org/$qkNCHc4PDARgf_dLGZAVvYUF-eSgE5pLxL4DhgIW6i8?via=matrix.org&via=invisiblethingslab.com&via=matrix.tu-berlin.de
- As of now, includes download and extraction scripts under blobs/xx30/download_extract_acm.sh - Adds x230-hotp-maximized-acm and x230-maximized-acm boards - Based on top of both linuxboot#1312 and linuxboot#1172 (coreboot 4.19 based) Next: attempt https://matrix.to/#/!WHWPvnIGPhGGtUFucJ:matrix.org/$qkNCHc4PDARgf_dLGZAVvYUF-eSgE5pLxL4DhgIW6i8?via=matrix.org&via=invisiblethingslab.com&via=matrix.tu-berlin.de
- As of now, includes download and extraction scripts under blobs/xx30/download_extract_acm.sh - Adds x230-hotp-maximized-acm and x230-maximized-acm boards - Based on top of both linuxboot#1312 and linuxboot#1172 (coreboot 4.19 based) Next: attempt https://matrix.to/#/!WHWPvnIGPhGGtUFucJ:matrix.org/$qkNCHc4PDARgf_dLGZAVvYUF-eSgE5pLxL4DhgIW6i8?via=matrix.org&via=invisiblethingslab.com&via=matrix.tu-berlin.de
|
To investigate and reuse to find ACM blob https://github.com/coreboot/coreboot/blob/master/util/cbfstool/fit.c#L353 |
|
Maybe bad news even on Haswell+ where ACM is supposed to be able to measure IBB through FIT descriptor but apparatly doesn't
Trace of discussions
|
tlaurion
changed the title
|
I gave up on TXT and switched to BtG 1.0 for enabling PCR-0 IBB measurements on the ProDrive Hermes board (C248 chipset, Cannonlake/Coffeelake): https://gist.github.com/ansiwen/255174aa96d6dc34680d95957d9d6fe9 |
|
Just to clarify the possibilities of TXT measuring the IBB to PCR0, a few things that have to be known:
We got to these conclusions with @ansiwen when researching the TXT IBB measurement possibilities. tl;dr Unless you have a real server board, don't go with TXT to measure IBB, you have to provision BootGuard for it... EDIT: Of course CBnT supported silicon (i.e IceLake+, CometLake-S +, TigerLake+) is another thing. IIRC no matter if you use BootGuard (with measurement) or TXT, IBB will be measured. |
|
Thanks @miczyg1 for the summary! To be honest, I'm still not convinced that it is not possible to enable TXT on the C246 chipset. I never tried to create the This was with the SACM of the Gigabyte C248-WU4 board (which has TXT support) and enabled TXT bit. |
|
@ansiwen I believe we cannot get over this one:
The CPU simply won't load the TXT BIOS ACM if it is not SACM |
|
A TXT SACM for the C62X chipset can be found in this firmware: https://www.intel.de/content/www/de/de/download/18911/intel-server-board-s2600wf-family-bios-and-firmware-update-package-for-uefi.html |
Despite that, ACMs have a Processor ID list (see https://cdrdv2.intel.com/v1/dl/getContent/315168 Table 13 and Table 14), which will prevent loading the ACM on arbitrary processors, like non-server ones in case of the ACM you are talking about. |
@miczyg1 Sure, but the BtG SACM seems to have some TXT support, because it reacts to the TXT bit, and the Gigabyte board officially has TXT support in the BIOS settings. And I wonder what would happen if this TXT support would be successfully enabled. |
Sure, I just wanted to share the find, in case someone has a compatible chipset. |
That is yet another path maybe worth exploring. That said, you will need both ACMs in such case:
And see what happens |
Compatible chipset AND CPU :) |
|
So if I get this all well, the only way around this is to forget about IBB measured bootblock and go trenchboot's way, enabling drtm with acm blobs from ivy bridge and up and go integrate trenchboot so that SLCM will be responsible to verify that the bootblock matches checksum inside of cbfs whenever requested up to whatever is desired to be measured? From what I'm reading above, SRTM with SACM measuring bootblock as part of IBB is reserved to server platforms only and cannot be generalized. Per prior work, Haswell and previous board configs under Heads have "platform locking" prepared by coreboot and enabled prior of final kexec call, locking write access to SPI from OS as of today. I'm still wrapping my head around how different drtm would prevent tampering of both bootblock and bootblock hash in cbfs but it seems that energy invested should go in that direction which should continue under an Heads specific trenchboot integration issue. @miczyg1 thoughts/corrections? |
Not sure what SLCM is. There is no point in verifying bootblock in CBFS against its checksum in CBFS, both things can be replaced to malicious content. |
@miczyg1 I meant SACM/ACM, typo. What I meant, again, is that if sinit+ACM blobs permits to add bootblock under IBB under FIT, it should be possible to have CPU RoT withtout bootguard, otherwise i'm still missing something I would love to understand once and for all. Another issue was created under system76/firmware-open#396 with similar concepts implied. I asked about this in both general and random dasharo channels and crosslinked the posts:
|
Answered at https://matrix.to/#/!rsKWMJGPMsyPTTjXuh:matrix.org/$BrErJTOamhiyDOIsXDPUSRAObTPrsEt4EFSMz97qxwU?via=matrix.org&via=nitro.chat&via=invisiblethingslab.com by @miczyg1
|
As of today
OLD:
I stayed up late last nights, reading the amazing blog posts from @3mdeb, more specifically their Fobnail articles, and kept on thinking about limitation of Heads having no RoT anchored in hardware.
Reread coreboot documentation on TXT, specifically ACM and IBB. I gave it a shot a couple of years back, without any success.
Reread the blogs post on Dasharo support of Optiplex and realized that a lot of problems linked to TXTin coreboot on Ivy bridge (xx30) were resolved by 3mdeb (thanks @miczyg1!!!). Followed the rabbit and saw that they were merged end of 2021....
Then the lines
I decided to give it a shot again. Can the ACM BIOS be downloaded just like ME was on the oath for maximized boards configurations?
Last time I digged into this enough (which lead to the Maximized support with ME neutered), it took a lot of digging to realize that Lenovo was gentle enough to distribute ME themselves from their website!
I digged deeper in the work that @3mdeb did on Optiplex, specifically their fwdeploy work, to realize that it might be highly probable that the ACM BIOS blob shared the same GUID across all Ivy boards.... Ran UEFIExtract on backups, and found the same ACM blob sharing the same GUID!
And then decided to download latest available x230 firmware executable from Lenovo, do the same thing I've done in the past to extract ME.... to realize that Lenovo is distributing the ACM BIOS blob themselves and that like ME, it can be directly downloaded and extracted.
So long story short, blobs/xx30/download_extract_acm.sh in this PR is the beginning of a PoC.
Hopefully, it will take less long then for the Maximized boards to be debugged and understand what was going wrong.
So here attached is the
cbmem -c -1log I took from an x230-hotp-maximized-acm flashed laptop, which complains that no IBB is defined and that TXT policies are missing, so no PCR0 containing IBB measurements.cbmem_logs.txt
The documentation is so sparse.... I hope the community will help me make blob based hardware RoT possible. With that, we should have PCR0 and bootblock measured, without the need to lock it down from flashrom, considering that locking the platform just before kexec is possible as well.
Help needed!
Todos:
Thank you to exist @3mdeb!!!!
@miczyg1 @pietrushnic : hints from the logs/link to documentation I missed?