GPIO locking is broken on Kaby Lake and possibly other platforms

[PeonyThePeon]

Mate Kukri (@kukrimate) filed an upstream bug in Coreboot: GPIO locking is broken on Kaby Lake and possibly other platforms.

Please can the Heads developers confirm if this bug negates one or more Heads security guarantees, and decide appropriate action if so?

Appropriate action might be:

• Update Heads documentation to warn current/prospective Heads users: which platforms are affected, and what the impact is;
• Fix the upstream bug;
• Something else.

[tlaurion]

@notgivenby answered on matrix

this issue is very well known. Actially, it is documented everywhere, including heads docs for the platform. Even in qubes forum there is note of that. I think really nice guys from coreboot solved the problem(in theory, but it should be implemented and tested). It looks like there is no huge interest in the community to do that.

I can add to that upstream coreboot topic to push forware (t480/t480s is community port)

• https://review.coreboot.org/q/topic:%22intel_gpio_lock%22

And remind Heads users that TPM GPIO issue is about using measured boot (PCR content), without encryption nor passphrase, targeting bad usage from Windows for bitlocker. Heads has no known impact from this, outside of TPM 1.2 platforms (older sandy/ivy bridge platforms ie x230/t430 which are not known to be vulnerable to this, but without parameters encryption as with TPM 2.0) which is theoritically not affected by this.

TLDR: on T480 (skylake+ affected and on which work was done but untested and non-functional as can be seen per https://review.coreboot.org/q/topic:%22intel_gpio_lock%22), this is TPM 2.0, which encrypts comms with TPM, relaying on coreboot measured boot (unencrypted) plus Heads sealing/unsealing TPMTOTP encrypted (CBFS files: PGPG keyring+trustdb, config.user config override) and TPM Disk Unlock Key (DUK) if setup (which measures and seals/unseals LUKS header + unseals only with proper TPM DUK passphrase) which is not the same as Windows Bitlocker unsealing disk without prompting for passphrase to boot into windows, with/without user passphrase....

@PeonyThePeon What is missing in the docs? Reads boards/T480/.config, https://osresearch.net for T480 (eg https://osresearch.net/T480-maximized-flashing/) ? What doc have you read? Be useful in your report. Thanks

---

Reminder for posterity: Heads is not coreboot and coreboot is not Heads. Heads relies/is equivalent of what coreboot does correctly and piggy-backs on coreboot. coreboot bugs? coreboot work.

[tlaurion]

Feel free to reopen if you feel this issue was closed without resolution.

[tlaurion]

Actually https://osresearch.net/T480-maximized-flashing/ and https://osresearch.net/T480s-maximized-flashing/ don't talk about TPM GPIO. @notgivenby willing to add?

We can't expect all users (as can be seen with this opened issue) to read board configs it seems.

heads/boards/EOL_t480-hotp-maximized/EOL_t480-hotp-maximized.config

Lines 4 to 9 in 548526d

	# CAVEATS:
	# This board is vulnerable to a TPM reset attack, i.e. the PCRs are reset while the system is running.
	# This attack can be used to bypass measured boot when an attacker succeeds at modifying the SPI flash.
	# Also it can be used to extract FDE keys from a TPM.
	# The related coreboot issue contains more information: https://ticket.coreboot.org/issues/576
	# Make sure you understand the implications of the attack for your threat model before using this board.

This doesn;t say it doesn't affect Heads TPM2.0 platforms (encrypted comms when heads kicks in) nor TPM DUK passphrase based unsealing (also on top of TPM2), In all cases, this needs to be dealt on coreboot side, not Heads side which Heads already does what it should do. Not a Heads problem.

[tlaurion]

Followup on matrix channel

notgivenby: documentation is actually incomplete see #2159 (comment)

user not to blame:

• https://osresearch.net/T480-maximized-flashing/
• https://osresearch.net/T480s-maximized-flashing/

Don't have any TPM GPIO (reset) notes.

@macpijan are all Skylake+ (Clevo) also known to be vulnerable and collaboration should happen fixing coreboot at https://review.coreboot.org/q/topic:%22intel\_gpio\_lock%22 ?

Cross-posted for validation: https://matrix.to/#/!QRtGMVOaSYrKiAjFKA:matrix.org/$WQcW7DUIbUkFtwifF84yBs5QJfacO67dHPbO7VvwtVw?via=matrix.3mdeb.com&via=matrix.org&via=nitro.chat

You can push seller of said platform (Nitrokey):

• https://support.nitrokey.com/

cc @jans23 @nestire @PeonyThePeon @macpijan

[PeonyThePeon]

Actually https://osresearch.net/T480-maximized-flashing/ and https://osresearch.net/T480s-maximized-flashing/ don't talk about TPM GPIO.

Exactly.

Also, vendor sales pages do not mention the issue:

• NitroPad T480
• NitroPad T480s

[tlaurion]

Actually https://osresearch.net/T480-maximized-flashing/ and https://osresearch.net/T480s-maximized-flashing/ don't talk about TPM GPIO.

Exactly.

Also, vendors' sales pages do not mention the issue:

* [NitroPad T480](https://shop.nitrokey.com/shop/nitropad-t480-871)

* [NitroPad T480s](https://shop.nitrokey.com/shop/nitropad-t480s-872)

@jans23.

@PeonyThePeon push seller, being Nitrokey, to push coreboot ($$$) to fix issues on sold platforms. Unfortunately, this is community port on which Nitrokey makes profit and should incentivize issue resolution, time/$ allocation. TLDR: not my problem since documented and things docs related says to read boards configs notes, so... Not a Heads problem.

Making it really clear on forum should incentivize resources allocation to fix issue.

Otherwise, tagging here technical board owners per https://github.com/linuxboot/heads/blob/aedae4ff33848b2df77893b7d8cc95052202d495/doc/BOARDS_AND_TESTERS.md:

xx8x (Kaby Lake Refresh: Intel 8th Gen Mobile : ESU ended 12/31/2024)

• t480: @gaspar-ilom @doritos4mlady @MattClifton76 @notgivenby @akunterkontrolle @nestire (Nitrokey)
• t480s: @thickfont @kjkent @HarleyGodfrey @nestire (Nitrokey)

Docs at https://osresearch.net could be clearer, but yet again, coreboot issue.