Is TPM or Intel hardware required for heads to work?

[mikebdp2]

@osresearch I've looked through the heads docs and FAQ but couldn't find a clear answer. Maybe you've only tested heads on these few Thinkpads with TPM, however - what are the real requirements? What of the following coreboot hardware combinations could work with heads, at least theoretically?

1a) Intel (not necessarily a Thinkpad!) coreboot-supported board with a TPM
1b) Intel (not necessarily a Thinkpad!) coreboot-supported board without a TPM

2a) AMD coreboot-supported board with a TPM (i.e. ASUS AM1I-A with a TPM attached to its header)
2b) AMD coreboot-supported board without a TPM

3a) not-x86 coreboot-supported board with a TPM
3b) not-x86 coreboot-supported board without a TPM

Why "without a TPM" ?

The majority of TPMs are the closed hardware/firmware with possible backdoors - these aren't adding any security in my opinion! Luckily, there's a open hardware/firmware TPM - Nitrokey #690 - which is also USB so could be added to any PC, not just those with a TPM header. However, it costs €50/$60 with an expensive shipping (probably because "Made in USA/Europe" and sold from there; it would've costed just a fraction of that price with a free shipping, if from China) - this is comparable to a price of used coreboot-supported PC itself, so would be nice if the people could get a secure heads installation without a TPM.

Why "AMD" or "not-x86" ?

From my point of view: the coreboot-supported AMD boards are more free/secure than the Intel ones because almost all of them (with the exception of a very few like PCEngines APU2) don't have neither Intel ME nor AMD PSP and don't suffer from Intel-only vulnerabilities like Meltdown or Zombieload.

All my coreboot boards are AMD only, and I'm curious if it's theoretically possible to run heads on them - i.e. on AMD Lenovo G505S laptop which doesn't have a TPM inside.

[tlaurion]

Will try to answer the most succinctly I can

@osresearch I've looked through the heads docs and FAQ but couldn't find a clear answer. Maybe you've only tested heads on these few Thinkpads with TPM, however - what are the real requirements? What of the following coreboot hardware combinations could work with heads, at least theoretically?

Heads modified coreboot to initialize and use the TPM in romstage to measure coreboot parts before payload to establish root of trust in the TPM. That is, prior to coreboot ramstage, or any coreboot payload. Doing measurements in payload is not a sufficient path, since earlier parts cannot be verified. The lower the measurements, the better.

Patch in question against coreboot 4.8.1

The earliest possible. Relying on any other part of hardware would require later coreboot stages, and results in a less interesting root of trust.

For example, relying on Nitrokey/Librem Key requires coreboot to have finalized all its stage, launching the kernel payload, and trusting lower executed code and flashrom binaries inside of the ram decompressed initrd to measure the SPI flash regions it has access to to measure it. In that situation, there is no root of trust.

Otherwise, the actual libremkey-hotp-verification module is using TPM measurements and challenges stored secret with remote attestation of TPM as of now, replacing what the user would normally attest manually on his phone from scanned a QR code resulting in TOTP code. Those are the measurements that are taken by TPM inside of Heads

1a) Intel (not necessarily a Thinkpad!) coreboot-supported board with a TPM
1b) Intel (not necessarily a Thinkpad!) coreboot-supported board without a TPM

2a) AMD coreboot-supported board with a TPM (i.e. ASUS AM1I-A with a TPM attached to its header)
2b) AMD coreboot-supported board without a TPM

3a) not-x86 coreboot-supported board with a TPM
3b) not-x86 coreboot-supported board without a TPM

Why "without a TPM" ?

The majority of TPMs are the closed hardware/firmware with possible backdoors - these aren't adding any security in my opinion! Luckily, there's a open hardware/firmware TPM - Nitrokey #690 - which is also USB so could be added to any PC, not just those with a TPM header.

Per referred PR, one has to understand that those measurements are taken too way late to be even considered a root of trust, and requires trust of the entire ROM, including flashrom, kernel, coreboot, sha256 binaries. That plainly doesn't work as how and where the TPM is trusted for and why. Nitrokey requires coreboot, Linux and USB modules to be loaded, then fully trust flashrom, sha256sum and cbfs binaries to establish post possibly tampered root of trust....

However, it costs €50/$60 with an expensive shipping (probably because "Made in USA/Europe" and sold from there; it would've costed just a fraction of that price with a free shipping, if from China) - this is comparable to a price of used coreboot-supported PC itself, so would be nice if the people could get a secure heads installation without a TPM.

Why "AMD" or "not-x86" ?

From my point of view: the coreboot-supported AMD boards are more free/secure than the Intel ones because almost all of them (with the exception of a very few like PCEngines APU2) don't have neither Intel ME nor AMD PSP and don't suffer from Intel-only vulnerabilities like Meltdown or Zombieload.

Agreed. While those boards, G505S, are not supported by coreboot anymore or contains PSP.

All my coreboot boards are AMD only, and I'm curious if it's theoretically possible to run heads on them - i.e. on AMD Lenovo G505S laptop which doesn't have a TPM inside.

#453 : G505S: Not enough space in SPI to do anything useful.
#134 : KGPE-D16 kcma-d8 : coreboot dropped support in 4.11

Future requirements of Heads: coreboot 4.11+ supported, with VBOOT+Measured boot, relying on TPM to establish root of trust.

An interesting avenue to be checked would be this talk implementing STM inside of SMM (I know, looks shady because NSA... But the talk was actually really interesting and looked promising, since implementing a TPM inside of the SMM VM)

My personal opinion would be to invest time and energy to support RYF hardware ditching x86 altogether, but the road ahead is not easy and not paved as a low hanging fruit at all:

• https://ryf.fsf.org/news/raptor-talos-announcement

• https://doc.coreboot.org/contributing/project_ideas.html#support-power9-power8-in-coreboot

• Port Qubes to ppc64 [3 bitcoin bounty] QubesOS/qubes-issues#4318

• https://www.crowdsupply.com/libre-risc-v/m-class/updates/openpower-eula-released-fosdem-and-more

[tlaurion]

@mikebdp2 in the case of the kgpe-d16, know that if there is interest, there is a refused NlNet fund project ready to receive interested peoples funds. The board has TPM slot, coreboot 4.9+ supports it, while required u-bmc work is also in the quote.

[tlaurion]

@mikebdp2 cross post: the TPM-less implementation you are talking about would be NSA software TPM implemented in SMM. Unfortunately, that talk is not available online (was not filmed if I recall well).

Thread:

• https://www.reddit.com/r/coreboot/comments/fjeyt7/stm_do_you_trust_it/

Github:

• https://github.com/EugeneDMyers/STM

[tlaurion]

@mikebdp2 : I would be really interested in reading your feedback on those updated issues.

[mikebdp2]

@tlaurion

Heads modified coreboot to initialize and use the TPM in romstage to measure coreboot parts before payload to establish root of trust in the TPM.

1) Are these TPM measurements done by a proprietary hardware TPM ? If that's so, by some trigger this TPM could enter a "backdoor mode" and report the last successful TPM measurements / prints done for "old coreboot" - for a new coreboot that has been tampered with. What do you think about it?

2) Are there any open hardware TPM with a "TPM header" interface - or only the USB ones?

3) Why a USB would't work? Look at these options from coreboot's menuconfig -> Generic Drivers:

│ │ [X] USB 2.0 EHCI debug dongle support ----- (CONFIG_USBDEBUG)
│ │ [X] Enable early (pre-RAM) usbdebug ----- (CONFIG_USBDEBUG_IN_PRE_RAM)
│ │ (0) Index for EHCI controller to use with usbdebug ----- (CONFIG_USBDEBUG_HCD_INDEX)
│ │ (0) Default USB port to use as Debug Port ----- (CONFIG_USBDEBUG_DEFAULT_PORT)
│ │ Type of dongle (FTDI FT232H UART) ---> (CONFIG_USBDEBUG_DONGLE_FTDI_FT232H)
│ │ (115200) FTDI FT232H baud rate ----- (CONFIG_USBDEBUG_DONGLE_FTDI_FT232H_BAUD)

They enable the output of verbose coreboot logs to a USB FT232H EHCI debug dongle plugged into a USB 2.0 port - and it starts printing these logs really early! Helped me to debug the AGESA RAM init while I've been adding the XMP memory profiles / custom timings support to AGESA boards:

https://review.coreboot.org/q/topic:%22AMD_XMP%22+(status:open%20OR%20status:merged)

By the way, these changes - could help KGPE-D16 to work with "unsupported" RAM modules, if you'd guess the right RAM timings for overriding their SPD values with which KGPE-D16 doesn't boot.

Seeing this success with FT232H, I don't understand - why a USB TPM couldn't work for your purposes. Maybe even a FT232H could be a partial substitute for TPM, if you'd output some custom log sequence that a hacked coreboot won't output or output differently - but, if not, a route similar to FT232H could be followed to get an early interface with a USB TPM.

While those boards, G505S, are not supported by coreboot anymore

only AMD fam10h boards (which includes a powerful ASUS KGPE-D16) aren't supported anymore. But the rest of AMD architectures and boards:

• fam14h , i.e.: Gizmo 1, PC Engines APU1, AsRock E350M1
• fam15h , i.e.: ASUS F2A85-M, ASUS A88XM-E, Lenovo G505S
• early fam16h , i.e.: ASUS AM1I-A, Biostar AM1ML

are supported by coreboot's master branch, while not having a PSP, and aren't going to be dropped.

I wonder if the efforts required to bring back a fam10h to coreboot's master are really that high, considering these successful examples of other AMD archs could be re-used at least partially. By the way, if the fam10h code and a small part of KGPE-D16 own code will get "fixed", then the sibling boards like KFSN4-DRE could be returned to coreboot relatively easy.

Thank you for sharing this talk, although STM stuff doesn't seem to be compatible with AMD - and in any case, a less hardware dependent solution is preferable. "USB Debug" seems more promising.

[tlaurion]

@mikebdp2 (Edited since original reply. Please read last update)

Heads modified coreboot to initialize and use the TPM in romstage to measure coreboot parts before payload to establish root of trust in the TPM.

1) Are these TPM measurements done by a proprietary hardware TPM ?

Yes. Patch against 4.8.1

If that's so, by some trigger this TPM could enter a "backdoor mode" and report the last successful TPM measurements / prints done for "old coreboot" - for a new coreboot that has been tampered with. What do you think about it?

Probable. Costly, would target really specific user and probably require hardware access and unscrewing and tampering with motherboard, for which simpler solution is glitter.

2) Are there any open hardware TPM with a "TPM header" interface - or only the USB ones?

#503 as of now.

3) Why a USB would't work? Look at these options from coreboot's menuconfig -> Generic Drivers:

│ │ [X] USB 2.0 EHCI debug dongle support ----- (CONFIG_USBDEBUG) │ │ [X] Enable early (pre-RAM) usbdebug ----- (CONFIG_USBDEBUG_IN_PRE_RAM) │ │ (0) Index for EHCI controller to use with usbdebug ----- (CONFIG_USBDEBUG_HCD_INDEX) │ │ (0) Default USB port to use as Debug Port ----- (CONFIG_USBDEBUG_DEFAULT_PORT) │ │ Type of dongle (FTDI FT232H UART) ---> (CONFIG_USBDEBUG_DONGLE_FTDI_FT232H) │ │ (115200) FTDI FT232H baud rate ----- (CONFIG_USBDEBUG_DONGLE_FTDI_FT232H_BAUD)

They enable the output of verbose coreboot logs to a USB FT232H EHCI debug dongle plugged into a USB 2.0 port - and it starts printing these logs really early! Helped me to debug the AGESA RAM init while I've been adding the XMP memory profiles / custom timings support to AGESA boards:

Serial output is a really simple implementation (when there is a serial port, not USB). Could be feasible to extend USB serial support, so that cached output is serialized on USB when USB becomes avail, while from my experience, a lot cannot be captured from those USB dongles when attempting to debug early init problems, storing coreboot output in cbmem being the more interesting approach. My experience is detailed from here: #541 (comment). If you find anything there that was done wrong and where USB can be used earlier, then you get my attention.

While all libremkey-hotp-verification only relies on TPM measurements already stored in TPM to be used in an handshake to verify through HOTP with the USB Security dongle (which relies on a closed source smartcard to safeguard the Open Source firmware operations. Backdoor in smartcard?), TPM-less implementation relies on post payload verifiecation as of now and as an effect of that, is not really relevant to this project, unless booted from a verified ISO launched with io=relaxed to dump full rom and check against signed /boot versions, where a full rom (IFD unlocked, permitting to dump all blobs there, and verify integrity outside of what otherwise could be compromised in the ROM that is not providing any guarantee on integrity, as attempted in #307 to not only be able to access the BIOS ifd region.)

Like I said previously, the libremkey no-TPM implementation on itself relies on a lot of other userland tools, from already launched Linux payload, to verify that what is in the SPI flash was not tampered with. So too late. It relies on flashrom to backup IFD regions, then sha256sum binary to verify them, both binaries that could have been tampered with to report "everything is good" even though the firmware was tampered with.

I'm no hardware designer, but an Open Source TPM or SMM implementing a Open Source swtpm seems the most generic approach to take if proprietary TPM is to be mistrust totally. While the Open Source TPM means also some soldering on old boards (hard on refurbishing and repurposing on old hardware, with supply chain attacks and a lot of trust implied from workers), the swtpm approach could be generic and implemented "easily".

https://review.coreboot.org/q/topic:%22AMD_XMP%22+(status:open%20OR%20status:merged)

By the way, these changes - could help KGPE-D16 to work with "unsupported" RAM modules, if you'd guess the right RAM timings for overriding their SPD values with which KGPE-D16 doesn't boot.

That is really interesting.
Please comment on #719

Seeing this success with FT232H, I don't understand - why a USB TPM couldn't work for your purposes. Maybe even a FT232H could be a partial substitute for TPM, if you'd output some custom log sequence that a hacked coreboot won't output or output differently - but, if not, a route similar to FT232H could be followed to get an early interface with a USB TPM.

It could. Not saying it couldn't. Just saying that #335 and #493 are not doing what you think it does right now, and that the latter is stalled because of the issues raised previously: they require to trust software peaces that could be tampered with (flashrom, sha256sum) that would lie to you in a really more easier way and generalizable then using an obscure TPM backdoor that requires specific targeting and a lot of money.

While those boards, G505S, are not supported by coreboot anymore

only AMD fam10h boards (which includes a powerful ASUS KGPE-D16) aren't supported anymore. But the rest of AMD architectures and boards:

* fam14h , i.e.: Gizmo 1, PC Engines APU1, AsRock E350M1

* fam15h , i.e.: ASUS F2A85-M, ASUS A88XM-E, Lenovo G505S

* early fam16h , i.e.: ASUS AM1I-A, Biostar AM1ML

I do not have time to investigate those boards. But you are more then welcome to open tickets to have the community interested in those boards. I would help the community to upstream them inside of Heads if without PSP and other blobs.

are supported by coreboot's master branch, while not having a PSP, and aren't going to be dropped.

Awesome.

I wonder if the efforts required to bring back a fam10h to coreboot's master are really that high, considering these successful examples of other AMD archs could be re-used at least partially. By the way, if the fam10h code and a small part of KGPE-D16 own code will get "fixed", then the sibling boards like KFSN4-DRE could be returned to coreboot relatively easy.

See and comment #719. Tasks, milestones and funding proposition is all there by 3mdeb.

Thank you for sharing this talk, although STM stuff doesn't seem to be compatible with AMD - and in any case, a less hardware dependent solution is preferable. "USB Debug" seems more promising.

Lead the path in that direction! But i'm not aware of a USB open source TPM implementation that exists for the moment. If this is not true anymore, please comment #503

[pietrushnic]

@mikebdp2 cross post: the TPM-less implementation you are talking about would be NSA software TPM implemented in SMM. Unfortunately, that talk is not available online (was not filmed if I recall well).

There is a lot of confusion in this discussion. LibremKey/NitroKey are not TPMs. TPM is a module that complies with TCG specs.

@tlaurion STM has not much to do with TPM, this is a protection mechanism for correct DRTM implementation in Intel platforms. This code can help in taking control over SMI, this was a very important contribution and if every PC would have open STM world would be better. BTW AMD has also this concept although nobody implemented that in the open.

@mikebdp2 in part I agree with you AMD is in many ways better than Intel, but also it has not so good firmware support and adoption is not so widespread ergo commercial customers build mostly on Intel, not on AMD. Of course, that can change over time.

There are many ways for open TPM to e.g. use swtpms or Xen vTPMs in virtualized environments, wait for OpenTitian chip. I will talk a little bit about that during Qubes OS and 3mdeb minisummit 2020

[tlaurion]

@mikebdp2 cross post: the TPM-less implementation you are talking about would be NSA software TPM implemented in SMM. Unfortunately, that talk is not available online (was not filmed if I recall well).

There is a lot of confusion in this discussion. LibremKey/NitroKey are not TPMs. TPM is a module that complies with TCG specs.

@tlaurion STM has not much to do with TPM, this is a protection mechanism for correct DRTM implementation in Intel platforms. This code can help in taking control over SMI, this was a very important contribution and if every PC would have open STM world would be better. BTW AMD has also this concept although nobody implemented that in the open.

@pietrushnic My understanding of the OSFC talk from Eugene was that SMM could be used to launch a VM which would run the swtpm. This is why I sent @mikebdp2 in this direction if goal would be to have a TPM-less (software enforced TPM). But no expertise here. Just an insight, which doesn't fill his AMD requirement anyway. Agreeing with the rest.

@mikebdp2 in part I agree with you AMD is in many ways better than Intel, but also it has not so good firmware support and adoption is not so widespread ergo commercial customers build mostly on Intel, not on AMD. Of course, that can change over time.

There are many ways for open TPM to e.g. use swtpms or Xen vTPMs in virtualized environments, wait for OpenTitian chip. I will talk a little bit about that during Qubes OS and 3mdeb minisummit 2020

[tlaurion]

@pietrushnic you might have expertise to bonify #701 if you have any good advices there. (Missing from Heads: swtpm, USB passthrough and virtual drives so Heads can be tested without physical hardware for a specific commit ID.)

[tlaurion]

@pietrushnic missing link is how to make that swtpm launched by SMM. G505s and other PSP less platforms could then have some interesting RoT, but that seems out of scope with your insight that AMD has not open source implementation.

[pietrushnic]

@tlaurion there is no open-source implementation for AMD I'm aware of. This would have to be written from scratch. Experts in this field claim it would be a completely different thing then Intel STM.

@pietrushnic My understanding of the OSFC talk from Eugene was that SMM could be used to launch a VM which would run the swtpm. This is why I sent @mikebdp2 in this direction if goal would be to have a TPM-less (software enforced TPM). But no expertise here. Just an insight, which doesn't fill his AMD requirement anyway. Agreeing with the rest.

Ok, it can be used for various things, and definitely some TPM would be needed if we want to have PCRs or other trusted computing primitives.

[pietrushnic]

@pietrushnic you might have expertise to bonify #701 if you have any good advices there. (Missing from Heads: swtpm, USB passthrough and virtual drives so Heads can be tested without physical hardware for a specific commit ID.)

As I said I'm working on gathering the state of SRTM support in QEMU, we will see what I will find. Right now I reached the maintainer of swtpm and get some hints, as well as I, started reading Xen vTPM stuff. Feel free to ping me if there is anything specific, definitely, I cannot go through alls threads to catch up on all possible details.

[tlaurion]

@pietrushnic #516 (comment)

And

https://github.com/tpm2-software/tpm2-tcti-uefi/blob/master/lib/efi-test-setup.sh