GPIO locking is broken on Kaby Lake and possibly other platforms

@kukrimate

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.

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

@jans23

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

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:

@jans23

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.

@nestire

doc/BOARDS_AND_TESTERS.md : make clear @nestire board owner of T480 s…

@PeonyThePeon push seller, being Nitrokey, to push coreboot to fix issues on sold platforms.

I'm grateful for your responses and for your work on Heads, but I have to push back a bit here.

I have no relationship with Nitrokey. Why would they pay attention to me - a random person online?

Heads devs do have a relationship with Nitrokey. Nitrokey trusts Heads devs implicitly: their products rely on your firmware. If the issue gets fixed, it is good for Nitrokey (more secure products, less risk of unhappy customers) and good for Heads (people won't see "there is a massive vulnerability (this one) on the heads firmware" and think Heads must suck). Win-win. => Heads devs should co-ordinate with Nitrokey.

not my problem since documented and things docs related says to read boards configs notes, so... Not a Heads problem.

I can't see anything in the Heads docs for T480 pointing to the relevant Coreboot docs or bug report. Am I overlooking something on that page?

If I'm not missing something, then the failure to acknowledge the issue in the Heads docs should, I hope, be easy to correct, and within the remit of Heads.

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

I'm not sure which forum you mean? Or who you want to make what clear.

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

But those are Heads docs aren't they, not Coreboot docs? So any shortcomings they have are a Heads issue. Or does the Coreboot project maintain the Heads Wiki?

matrix.org is just one of many homeservers, see https://osresearch.net/community/

EG: Tested (No e-mail required at registration, tor friendly) home server: the-apothecary.club

But maybe outdated, that was written in 2024 linuxboot/heads-wiki@42685d6

Thanks. You're right, that info is outdated: says lurking is possible, but AFAICT that is no longer true; likewise joining without email. Maybe remove the hostages to fortune & simplify the page? Should I do a PR? If so, I'll try to get to it later this week.

Cheers for highlighting other homeservers. My brain is tired from decisions today. I'll try joining Matrix again in a few days, evaluating other homeservers if needed.

Here, i'm working on docs (heads-wiki user facing docs ...) while trying to verify which platforms are affected and to which degree

Awesome, thank you! 🎉

Should I do a PR? If so, I'll try to get to it later this week.

I would really appreciate, getting a bit overwhelmed here :/

One issue per subject, and ideally one PR per reported issue to fix.

Need review for both

Heads-threat-model: per-board GPIO TPM reset protection table; uniformise 20 board flashing guide pages heads-wiki#221 ( with rendered pages to review at Heads-threat-model: per-board GPIO TPM reset protection table; uniformise 20 board flashing guide pages heads-wiki#221 (comment))
doc: document TPM GPIO reset vulnerability and per-board lock status #2161

Need review for both

Heads-threat-model: per-board GPIO TPM reset protection table; uniformise 20 board flashing guide pages heads-wiki#221 ( with rendered pages to review at Heads-threat-model: per-board GPIO TPM reset protection table; uniformise 20 board flashing guide pages heads-wiki#221 (comment))

doc: document TPM GPIO reset vulnerability and per-board lock status #2161

For what it's worth, it made sense to me and I don't have anywhere near the knowledge you guys have. Thank you for breaking it down like crayola

Need review for both

doc: add TPM GPIO reset vulnerability warning to all board flashing guides heads-wiki#221 ( with rendered pages to review at doc: add TPM GPIO reset vulnerability warning to all board flashing guides heads-wiki#221 (comment))

doc: document TPM GPIO reset vulnerability and per-board lock status #2161

Huge thanks for this. I have read most of it. Very informative and helpful so far. As Tim Peters said, "Explicit is better than implicit. Simple is better than complex."

Hope to read the rest and let it percolate later this week. Thank you again.

@nestire

doc/BOARDS_AND_TESTERS.md : make clear @nestire board owner of T480 s…

both PRs lgtm. for the record we already discussed during the initial port #1906 (comment)
looks like a lot of work went into documentation now.

on a sidenote. is it worth asking nitrokey for a donation to the heads project because they sell t480(s) boards with heads. they should consider it at least...

@nestire

doc/BOARDS_AND_TESTERS.md : make clear @nestire board owner of T480 s…

Navigation Menu

Repository navigation

GPIO locking is broken on Kaby Lake and possibly other platforms #2159

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

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

GPIO locking is broken on Kaby Lake and possibly other platforms #2159

Description

Activity

tlaurion commented on Jul 20, 2026

tlaurion commented on Jul 20, 2026

tlaurion commented on Jul 20, 2026

tlaurion commented on Jul 20, 2026

PeonyThePeon commented on Jul 20, 2026

tlaurion commented on Jul 20, 2026

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

PeonyThePeon commented on Jul 21, 2026

16 remaining items

PeonyThePeon commented on Jul 21, 2026

tlaurion commented on Jul 21, 2026

tlaurion commented on Jul 22, 2026

MattClifton76 commented on Jul 22, 2026

PeonyThePeon commented on Jul 22, 2026

gaspar-ilom commented on Jul 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions