Bug #576
openGPIO locking is broken on Kaby Lake and possibly other platforms
Added by Mate Kukri over 1 year ago. Updated 3 days ago.
0%
Description
Many supported Kaby Lake boards (and possibly newer platforms as well) are vulnerable to TPM GPIO reset attacks.
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.
NC Updated by Nicholas Chin 6 months ago · Edited Actions #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 callssoc_lock_gpios(). This requires that the platform implement asoc_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 ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected. -
soc/intel/common/block/gpio/gpio.c:gpio_lock_pad(), which callsgpio_lock_pads()if called from SMM code. This does not suffer from thesoc_gpio_lock_config()described above, but this is almost always called from ramstage through thegpio_configure_pads()>gpio_configure_pad()call stack. The one exception ismb/google/dedede, which calls it from a mainboard SMI handler. It will also callgpio_lock_pads()ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected, even if called from ramstage, but this will also fail to lock the pads asgpio_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 ("soc/intel/common/gpio: Perform GPIO PAD lock outside SMM").
Commit 222852a26476 ("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.
NC Updated by Nicholas Chin 6 months ago Actions #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.
DR Updated by Dan Ran 3 months ago Actions #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()andgpio_non_smm_lock_pad(), both insoc/intel/common/block/gpio/gpio.c.
gpio_lock_pads()can only be called from SMM, and requires thatSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis 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 callssoc_lock_gpios(). This requires that the platform implement asoc_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 ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected.soc/intel/common/block/gpio/gpio.c:gpio_lock_pad(), which callsgpio_lock_pads()if called from SMM code. This does not suffer from thesoc_gpio_lock_config()described above, but this is almost always called from ramstage through thegpio_configure_pads()>gpio_configure_pad()call stack. The one exception ismb/google/dedede, which calls it from a mainboard SMI handler. It will also callgpio_lock_pads()ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected, even if called from ramstage, but this will also fail to lock the pads asgpio_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 fromgpio_lock_pad()if outside of SMM (almost always true as mentioned above) and ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis NOT selected. For this function to perform the lock, eitherSOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCRorSOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_SBImust 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 allsoc/intelplatforms prior to this that use the common GPIO code.The latter method was added in commit fe678cbd195d ("soc/intel/common/gpio: Perform GPIO PAD lock outside SMM").
Commit 222852a26476 ("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/+/90885Still 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/+/90885Still 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?
MK Updated by Mate Kukri 3 months ago Actions #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()andgpio_non_smm_lock_pad(), both insoc/intel/common/block/gpio/gpio.c.
gpio_lock_pads()can only be called from SMM, and requires thatSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis 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 callssoc_lock_gpios(). This requires that the platform implement asoc_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 ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected.soc/intel/common/block/gpio/gpio.c:gpio_lock_pad(), which callsgpio_lock_pads()if called from SMM code. This does not suffer from thesoc_gpio_lock_config()described above, but this is almost always called from ramstage through thegpio_configure_pads()>gpio_configure_pad()call stack. The one exception ismb/google/dedede, which calls it from a mainboard SMI handler. It will also callgpio_lock_pads()ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected, even if called from ramstage, but this will also fail to lock the pads asgpio_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 fromgpio_lock_pad()if outside of SMM (almost always true as mentioned above) and ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis NOT selected. For this function to perform the lock, eitherSOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCRorSOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_SBImust 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 allsoc/intelplatforms prior to this that use the common GPIO code.The latter method was added in commit fe678cbd195d ("soc/intel/common/gpio: Perform GPIO PAD lock outside SMM").
Commit 222852a26476 ("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/+/90885Still 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/+/90885Still 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
DR Updated by Dan Ran 2 months ago Actions #5
Mate Kukri wrote in #note-4:
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
I have a T480 with Heads on it as we speak. However, i dont think I'm knowledeable enough to implement whatever you want me to implement without some proper instructions. Is there anything I can do to help or can I test something on my T480 for you?
TL Updated by Thierry Laurion 3 days ago · Edited Actions #6
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()andgpio_non_smm_lock_pad(), both insoc/intel/common/block/gpio/gpio.c.
gpio_lock_pads()can only be called from SMM, and requires thatSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis 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 callssoc_lock_gpios(). This requires that the platform implement asoc_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 ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected.soc/intel/common/block/gpio/gpio.c:gpio_lock_pad(), which callsgpio_lock_pads()if called from SMM code. This does not suffer from thesoc_gpio_lock_config()described above, but this is almost always called from ramstage through thegpio_configure_pads()>gpio_configure_pad()call stack. The one exception ismb/google/dedede, which calls it from a mainboard SMI handler. It will also callgpio_lock_pads()ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis selected, even if called from ramstage, but this will also fail to lock the pads asgpio_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 fromgpio_lock_pad()if outside of SMM (almost always true as mentioned above) and ifSOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADSis NOT selected. For this function to perform the lock, eitherSOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCRorSOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_SBImust 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 allsoc/intelplatforms prior to this that use the common GPIO code.The latter method was added in commit fe678cbd195d ("soc/intel/common/gpio: Perform GPIO PAD lock outside SMM").
Commit 222852a26476 ("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/+/90885Still 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/+/90885Still 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 (Clevo nv4x_adl) also vulnerable: https://github.com/linuxboot/heads/pull/2165#issuecomment-5138700385
# ---- Under Heads ----
# 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
# ---- Under Host ----
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.
MK Updated by Mate Kukri 3 days ago Actions #7
Unfortunately most devices up until a certain point are vulnerable, it seems to me that Intel decided to do nothing about this, and probably did not inform any OEMs either.