diff --git a/Makefile b/Makefile index d103e7ac0..ff2cf39e0 100644 --- a/Makefile +++ b/Makefile @@ -750,6 +750,7 @@ bin_modules-$(CONFIG_NKSTORECLI) += nkstorecli bin_modules-$(CONFIG_UTIL_LINUX) += util-linux bin_modules-$(CONFIG_OPENSSL) += openssl bin_modules-$(CONFIG_TPM2_TOOLS) += tpm2-tools +bin_modules-$(CONFIG_TPM2_TOOLS) += tpm-gpio-reset bin_modules-$(CONFIG_BASH) += bash bin_modules-$(CONFIG_POWERPC_UTILS) += powerpc-utils bin_modules-$(CONFIG_IO386) += io386 diff --git a/blobs/m900/README.md b/blobs/m900/README.md index 2ba846ad0..c75878296 100644 --- a/blobs/m900/README.md +++ b/blobs/m900/README.md @@ -39,7 +39,7 @@ Sha256sums: `blobs/m900/hashes.txt` # CAVEATS for the board: -> This board is vulnerable to a TPM reset attack, i.e. the PCRs are reset while the system is running. +> This board is vulnerable to a TPM GPIO 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 diff --git a/blobs/xx80/README.md b/blobs/xx80/README.md index 4451931a0..87fbac58b 100644 --- a/blobs/xx80/README.md +++ b/blobs/xx80/README.md @@ -42,7 +42,7 @@ Sha256sums: `blobs/xx80/hashes.txt` See the board configs `boards/t480-[hotp-]maximized/t480-[hotp-]maximized.config`: -> This board is vulnerable to a TPM reset attack, i.e. the PCRs are reset while the system is running. +> This board is vulnerable to a TPM GPIO 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 diff --git a/boards/EOL_UNTESTED_t530-hotp-maximized/EOL_UNTESTED_t530-hotp-maximized.config b/boards/EOL_UNTESTED_t530-hotp-maximized/EOL_UNTESTED_t530-hotp-maximized.config index a6f4f7371..97852bc3d 100644 --- a/boards/EOL_UNTESTED_t530-hotp-maximized/EOL_UNTESTED_t530-hotp-maximized.config +++ b/boards/EOL_UNTESTED_t530-hotp-maximized/EOL_UNTESTED_t530-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a T530 running Qubes and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_UNTESTED_t530-maximized/EOL_UNTESTED_t530-maximized.config b/boards/EOL_UNTESTED_t530-maximized/EOL_UNTESTED_t530-maximized.config index 3e57c6b8a..4fa736382 100644 --- a/boards/EOL_UNTESTED_t530-maximized/EOL_UNTESTED_t530-maximized.config +++ b/boards/EOL_UNTESTED_t530-maximized/EOL_UNTESTED_t530-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a T530 running Qubes and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_librem_13v2/EOL_librem_13v2.config b/boards/EOL_librem_13v2/EOL_librem_13v2.config index 53ccf1ceb..9db0e4c24 100644 --- a/boards/EOL_librem_13v2/EOL_librem_13v2.config +++ b/boards/EOL_librem_13v2/EOL_librem_13v2.config @@ -1,6 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a librem_13v2 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_13v2.config export CONFIG_COREBOOT=y diff --git a/boards/EOL_librem_13v4/EOL_librem_13v4.config b/boards/EOL_librem_13v4/EOL_librem_13v4.config index 6a233e4cf..3dfe7d6e3 100644 --- a/boards/EOL_librem_13v4/EOL_librem_13v4.config +++ b/boards/EOL_librem_13v4/EOL_librem_13v4.config @@ -1,6 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a librem_13v4 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_13v4.config export CONFIG_COREBOOT=y diff --git a/boards/EOL_librem_15v3/EOL_librem_15v3.config b/boards/EOL_librem_15v3/EOL_librem_15v3.config index b1cfbb21b..c78de9a54 100644 --- a/boards/EOL_librem_15v3/EOL_librem_15v3.config +++ b/boards/EOL_librem_15v3/EOL_librem_15v3.config @@ -1,6 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a librem_15v3 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_15v3.config export CONFIG_COREBOOT=y diff --git a/boards/EOL_librem_15v4/EOL_librem_15v4.config b/boards/EOL_librem_15v4/EOL_librem_15v4.config index 2236667db..cc6ed4c71 100644 --- a/boards/EOL_librem_15v4/EOL_librem_15v4.config +++ b/boards/EOL_librem_15v4/EOL_librem_15v4.config @@ -1,6 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a librem_15v4 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_15v4.config export CONFIG_COREBOOT=y diff --git a/boards/EOL_librem_l1um/EOL_librem_l1um.config b/boards/EOL_librem_l1um/EOL_librem_l1um.config index 2b4c41fed..17ca10cdc 100644 --- a/boards/EOL_librem_l1um/EOL_librem_l1um.config +++ b/boards/EOL_librem_l1um/EOL_librem_l1um.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a librem_l1um CONFIG_LINUX_CONFIG=config/linux-librem_common.config CONFIG_COREBOOT_CONFIG=config/coreboot-librem_l1um.config diff --git a/boards/EOL_m900_tower-hotp-maximized/EOL_m900_tower-hotp-maximized.config b/boards/EOL_m900_tower-hotp-maximized/EOL_m900_tower-hotp-maximized.config index 2051e15f7..5d7cbf034 100644 --- a/boards/EOL_m900_tower-hotp-maximized/EOL_m900_tower-hotp-maximized.config +++ b/boards/EOL_m900_tower-hotp-maximized/EOL_m900_tower-hotp-maximized.config @@ -18,13 +18,8 @@ # - PSU: 250W (85% efficiency) or optional 400W (92%) # - Form factor: Mini Tower (25L), 175 x 413 x 406 mm, ~12.5 kg # -# 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. -# Includes +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # - Deactivated+partially neutered+deguarded ME and expanded consequent IFD BIOS regions # - More details can be found in the script under blobs/m900/m900_download_clean_deguard_me.sh # - Forged GBE MAC address to 00:DE:AD:C0:FF:EE diff --git a/boards/EOL_m900_tower-maximized/EOL_m900_tower-maximized.config b/boards/EOL_m900_tower-maximized/EOL_m900_tower-maximized.config index 810163ecd..8eb16cb96 100644 --- a/boards/EOL_m900_tower-maximized/EOL_m900_tower-maximized.config +++ b/boards/EOL_m900_tower-maximized/EOL_m900_tower-maximized.config @@ -18,13 +18,8 @@ # - PSU: 250W (85% efficiency) or optional 400W (92%) # - Form factor: Mini Tower (25L), 175 x 413 x 406 mm, ~12.5 kg # -# 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. -# Includes +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # - Deactivated+partially neutered+deguarded ME and expanded consequent IFD BIOS regions # - More details can be found in the script under blobs/m900/m900_download_clean_deguard_me.sh # - Forged GBE MAC address to 00:DE:AD:C0:FF:EE diff --git a/boards/EOL_optiplex-7010_9010-hotp-maximized/EOL_optiplex-7010_9010-hotp-maximized.config b/boards/EOL_optiplex-7010_9010-hotp-maximized/EOL_optiplex-7010_9010-hotp-maximized.config index e50aeb232..5e4ccce60 100644 --- a/boards/EOL_optiplex-7010_9010-hotp-maximized/EOL_optiplex-7010_9010-hotp-maximized.config +++ b/boards/EOL_optiplex-7010_9010-hotp-maximized/EOL_optiplex-7010_9010-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a Optiplex 7010/9010 SFF running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_optiplex-7010_9010-maximized/EOL_optiplex-7010_9010-maximized.config b/boards/EOL_optiplex-7010_9010-maximized/EOL_optiplex-7010_9010-maximized.config index 917638768..d57983b68 100644 --- a/boards/EOL_optiplex-7010_9010-maximized/EOL_optiplex-7010_9010-maximized.config +++ b/boards/EOL_optiplex-7010_9010-maximized/EOL_optiplex-7010_9010-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a Optiplex 7010/9010 SFF running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_optiplex-7010_9010_TXT-hotp-maximized/EOL_optiplex-7010_9010_TXT-hotp-maximized.config b/boards/EOL_optiplex-7010_9010_TXT-hotp-maximized/EOL_optiplex-7010_9010_TXT-hotp-maximized.config index 9c318dc57..5b9d2cfc9 100644 --- a/boards/EOL_optiplex-7010_9010_TXT-hotp-maximized/EOL_optiplex-7010_9010_TXT-hotp-maximized.config +++ b/boards/EOL_optiplex-7010_9010_TXT-hotp-maximized/EOL_optiplex-7010_9010_TXT-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a Optiplex 7010/9010 SFF running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_optiplex-7010_9010_TXT-maximized/EOL_optiplex-7010_9010_TXT-maximized.config b/boards/EOL_optiplex-7010_9010_TXT-maximized/EOL_optiplex-7010_9010_TXT-maximized.config index 3e1cea776..69154c329 100644 --- a/boards/EOL_optiplex-7010_9010_TXT-maximized/EOL_optiplex-7010_9010_TXT-maximized.config +++ b/boards/EOL_optiplex-7010_9010_TXT-maximized/EOL_optiplex-7010_9010_TXT-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a Optiplex 7010/9010 SFF running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_t420-hotp-maximized/EOL_t420-hotp-maximized.config b/boards/EOL_t420-hotp-maximized/EOL_t420-hotp-maximized.config index c2f4e86df..8fd55401b 100644 --- a/boards/EOL_t420-hotp-maximized/EOL_t420-hotp-maximized.config +++ b/boards/EOL_t420-hotp-maximized/EOL_t420-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a T420 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_t420-maximized/EOL_t420-maximized.config b/boards/EOL_t420-maximized/EOL_t420-maximized.config index a797cb650..9442cc474 100644 --- a/boards/EOL_t420-maximized/EOL_t420-maximized.config +++ b/boards/EOL_t420-maximized/EOL_t420-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a T420 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_t430-hotp-maximized/EOL_t430-hotp-maximized.config b/boards/EOL_t430-hotp-maximized/EOL_t430-hotp-maximized.config index f44bab884..14f7861b9 100644 --- a/boards/EOL_t430-hotp-maximized/EOL_t430-hotp-maximized.config +++ b/boards/EOL_t430-hotp-maximized/EOL_t430-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a T430 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_t430-maximized/EOL_t430-maximized.config b/boards/EOL_t430-maximized/EOL_t430-maximized.config index 26b5805cd..b885744bf 100644 --- a/boards/EOL_t430-maximized/EOL_t430-maximized.config +++ b/boards/EOL_t430-maximized/EOL_t430-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a T430 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_t440p-hotp-maximized/EOL_t440p-hotp-maximized.config b/boards/EOL_t440p-hotp-maximized/EOL_t440p-hotp-maximized.config index 630a6e28d..39379753a 100644 --- a/boards/EOL_t440p-hotp-maximized/EOL_t440p-hotp-maximized.config +++ b/boards/EOL_t440p-hotp-maximized/EOL_t440p-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a ThinkPad T440p with HOTP Security dongle support CONFIG_COREBOOT_CONFIG=config/coreboot-t440p.config # TODO: Make a ThinkPad-common Linux config file. diff --git a/boards/EOL_t440p-maximized/EOL_t440p-maximized.config b/boards/EOL_t440p-maximized/EOL_t440p-maximized.config index ce9de9dec..82dde73bd 100644 --- a/boards/EOL_t440p-maximized/EOL_t440p-maximized.config +++ b/boards/EOL_t440p-maximized/EOL_t440p-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a ThinkPad T440p without HOTP Security dongle support CONFIG_COREBOOT_CONFIG=config/coreboot-t440p.config # TODO: Make a ThinkPad-common Linux config file. diff --git a/boards/EOL_t480-hotp-maximized/EOL_t480-hotp-maximized.config b/boards/EOL_t480-hotp-maximized/EOL_t480-hotp-maximized.config index b55eeca8b..70befdc5e 100644 --- a/boards/EOL_t480-hotp-maximized/EOL_t480-hotp-maximized.config +++ b/boards/EOL_t480-hotp-maximized/EOL_t480-hotp-maximized.config @@ -1,14 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a T480 running Qubes 4.2.3 and other Linux Based OSes (through kexec) # -# 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. -# -# Includes +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # - Deactivated+partially neutered+deguarded ME and expanded consequent IFD BIOS regions # - More details can be found in the script under blobs/xx80/download_clean_deguard_me_pad_tb.sh # - Forged GBE MAC address to 00:DE:AD:C0:FF:EE MAC address (if not extracting gbe.bin from backup with blobs/xx80/extract.sh) diff --git a/boards/EOL_t480-maximized/EOL_t480-maximized.config b/boards/EOL_t480-maximized/EOL_t480-maximized.config index 42f327f24..e7c4a50ce 100644 --- a/boards/EOL_t480-maximized/EOL_t480-maximized.config +++ b/boards/EOL_t480-maximized/EOL_t480-maximized.config @@ -1,14 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a T480 running Qubes 4.2.3 and other Linux Based OSes (through kexec) # -# 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. -# -# Includes +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # - Deactivated+partially neutered+deguarded ME and expanded consequent IFD BIOS regions # - More details can be found in the script under blobs/xx80/download_clean_deguard_me_pad_tb.sh # - Forged GBE MAC address to 00:DE:AD:C0:FF:EE MAC address (if not extracting gbe.bin from backup with blobs/xx80/extract.sh) diff --git a/boards/EOL_t480s-hotp-maximized/EOL_t480s-hotp-maximized.config b/boards/EOL_t480s-hotp-maximized/EOL_t480s-hotp-maximized.config index f1096f445..4f933d15c 100644 --- a/boards/EOL_t480s-hotp-maximized/EOL_t480s-hotp-maximized.config +++ b/boards/EOL_t480s-hotp-maximized/EOL_t480s-hotp-maximized.config @@ -1,14 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a T480 running Qubes 4.2.3 and other Linux Based OSes (through kexec) # -# 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. -# -# Includes +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # - Deactivated+partially neutered+deguarded ME and expanded consequent IFD BIOS regions # - More details can be found in the script under blobs/xx80/download_clean_deguard_me_pad_tb.sh # - Forged GBE MAC address to 00:DE:AD:C0:FF:EE MAC address (if not extracting gbe.bin from backup with blobs/xx80/extract.sh) diff --git a/boards/EOL_t480s-maximized/EOL_t480s-maximized.config b/boards/EOL_t480s-maximized/EOL_t480s-maximized.config index 0070d9e4b..b1478cbc8 100644 --- a/boards/EOL_t480s-maximized/EOL_t480s-maximized.config +++ b/boards/EOL_t480s-maximized/EOL_t480s-maximized.config @@ -1,14 +1,8 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use # Configuration for a T480 running Qubes 4.2.3 and other Linux Based OSes (through kexec) # -# 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. -# -# Includes +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # - Deactivated+partially neutered+deguarded ME and expanded consequent IFD BIOS regions # - More details can be found in the script under blobs/xx80/download_clean_deguard_me_pad_tb.sh # - Forged GBE MAC address to 00:DE:AD:C0:FF:EE MAC address (if not extracting gbe.bin from backup with blobs/xx80/extract.sh) diff --git a/boards/EOL_w530-hotp-maximized/EOL_w530-hotp-maximized.config b/boards/EOL_w530-hotp-maximized/EOL_w530-hotp-maximized.config index 5e23f47d3..21c3eef8d 100644 --- a/boards/EOL_w530-hotp-maximized/EOL_w530-hotp-maximized.config +++ b/boards/EOL_w530-hotp-maximized/EOL_w530-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a W530 running Qubes and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_w530-maximized/EOL_w530-maximized.config b/boards/EOL_w530-maximized/EOL_w530-maximized.config index 9daa35c55..a5e77ea6c 100644 --- a/boards/EOL_w530-maximized/EOL_w530-maximized.config +++ b/boards/EOL_w530-maximized/EOL_w530-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a W530 running Qubes and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_w541-hotp-maximized/EOL_w541-hotp-maximized.config b/boards/EOL_w541-hotp-maximized/EOL_w541-hotp-maximized.config index 6baa67129..f93d267cc 100644 --- a/boards/EOL_w541-hotp-maximized/EOL_w541-hotp-maximized.config +++ b/boards/EOL_w541-hotp-maximized/EOL_w541-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a ThinkPad W541 with HOTP security dongle support # For known issues see the blobs/w541/README.md CONFIG_COREBOOT_CONFIG=config/coreboot-w541.config diff --git a/boards/EOL_w541-maximized/EOL_w541-maximized.config b/boards/EOL_w541-maximized/EOL_w541-maximized.config index cb0b985d6..53a21174d 100644 --- a/boards/EOL_w541-maximized/EOL_w541-maximized.config +++ b/boards/EOL_w541-maximized/EOL_w541-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a ThinkPad W541 without HOTP security dongle support # For known issues see the blobs/w541/README.md CONFIG_COREBOOT_CONFIG=config/coreboot-w541.config diff --git a/boards/EOL_x220-hotp-maximized/EOL_x220-hotp-maximized.config b/boards/EOL_x220-hotp-maximized/EOL_x220-hotp-maximized.config index 6d7033db6..4fd0825cc 100644 --- a/boards/EOL_x220-hotp-maximized/EOL_x220-hotp-maximized.config +++ b/boards/EOL_x220-hotp-maximized/EOL_x220-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a X220 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_x220-maximized/EOL_x220-maximized.config b/boards/EOL_x220-maximized/EOL_x220-maximized.config index bb37026df..fdc5da0df 100644 --- a/boards/EOL_x220-maximized/EOL_x220-maximized.config +++ b/boards/EOL_x220-maximized/EOL_x220-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a X220 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_x230-hotp-maximized-fhd_edp/EOL_x230-hotp-maximized-fhd_edp.config b/boards/EOL_x230-hotp-maximized-fhd_edp/EOL_x230-hotp-maximized-fhd_edp.config index e3aa82e55..463839fd0 100644 --- a/boards/EOL_x230-hotp-maximized-fhd_edp/EOL_x230-hotp-maximized-fhd_edp.config +++ b/boards/EOL_x230-hotp-maximized-fhd_edp/EOL_x230-hotp-maximized-fhd_edp.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a X230 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Based on https://review.coreboot.org/c/coreboot/+/28950 for FHD mod diff --git a/boards/EOL_x230-hotp-maximized/EOL_x230-hotp-maximized.config b/boards/EOL_x230-hotp-maximized/EOL_x230-hotp-maximized.config index fc4ca0ce0..cb06d1899 100644 --- a/boards/EOL_x230-hotp-maximized/EOL_x230-hotp-maximized.config +++ b/boards/EOL_x230-hotp-maximized/EOL_x230-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a X230 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_x230-hotp-maximized_usb-kb/EOL_x230-hotp-maximized_usb-kb.config b/boards/EOL_x230-hotp-maximized_usb-kb/EOL_x230-hotp-maximized_usb-kb.config index 6131631ad..fff75bca8 100644 --- a/boards/EOL_x230-hotp-maximized_usb-kb/EOL_x230-hotp-maximized_usb-kb.config +++ b/boards/EOL_x230-hotp-maximized_usb-kb/EOL_x230-hotp-maximized_usb-kb.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a X230 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_x230-maximized-fhd_edp/EOL_x230-maximized-fhd_edp.config b/boards/EOL_x230-maximized-fhd_edp/EOL_x230-maximized-fhd_edp.config index 69058a82e..a7855c198 100644 --- a/boards/EOL_x230-maximized-fhd_edp/EOL_x230-maximized-fhd_edp.config +++ b/boards/EOL_x230-maximized-fhd_edp/EOL_x230-maximized-fhd_edp.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a X230 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Based on https://review.coreboot.org/c/coreboot/+/28950 for FHD mod diff --git a/boards/EOL_x230-maximized/EOL_x230-maximized.config b/boards/EOL_x230-maximized/EOL_x230-maximized.config index 40afeaeab..f5edab489 100644 --- a/boards/EOL_x230-maximized/EOL_x230-maximized.config +++ b/boards/EOL_x230-maximized/EOL_x230-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for a X230 running Qubes 4.1 and other Linux Based OSes (through kexec) # # Includes diff --git a/boards/EOL_z220-cmt-hotp-maximized/EOL_z220-cmt-hotp-maximized.config b/boards/EOL_z220-cmt-hotp-maximized/EOL_z220-cmt-hotp-maximized.config index 48d5d9c6a..600df1a24 100644 --- a/boards/EOL_z220-cmt-hotp-maximized/EOL_z220-cmt-hotp-maximized.config +++ b/boards/EOL_z220-cmt-hotp-maximized/EOL_z220-cmt-hotp-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for HP Z220 CMT with HOTP usb security dongle support # #The board supports Intel LGA1155, which allows for ME removal (both neuter+disable as claimed by me_cleaner), diff --git a/boards/EOL_z220-cmt-maximized/EOL_z220-cmt-maximized.config b/boards/EOL_z220-cmt-maximized/EOL_z220-cmt-maximized.config index 1bb026565..2f0d51c1f 100644 --- a/boards/EOL_z220-cmt-maximized/EOL_z220-cmt-maximized.config +++ b/boards/EOL_z220-cmt-maximized/EOL_z220-cmt-maximized.config @@ -1,4 +1,7 @@ # WARNING: This system remains perpetually vulnerable to Spectre v2 (CVE-2017-5715). Mitigations and microcode updates previously applied are now known to be ineffective due to QSB-107 and related CVEs. If Spectre v2 is a concern in your threat model, consider migrating to a platform with ongoing microcode support. Proper OPSEC for Memory Use MUST be followed:https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- dedicated PLTRST# pin, not shared with GPIO +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # Configuration for HP Z220 CMT without HOTP usb security dongle support # #The board supports Intel LGA1155, which allows for ME removal (both neuter+disable as claimed by me_cleaner), diff --git a/boards/UNTESTED_msi_z690a_ddr4/UNTESTED_msi_z690a_ddr4.config b/boards/UNTESTED_msi_z690a_ddr4/UNTESTED_msi_z690a_ddr4.config index 0fbf49897..467f1ac94 100644 --- a/boards/UNTESTED_msi_z690a_ddr4/UNTESTED_msi_z690a_ddr4.config +++ b/boards/UNTESTED_msi_z690a_ddr4/UNTESTED_msi_z690a_ddr4.config @@ -1,5 +1,6 @@ # MSI PRO Z690-A DDR4 board configuration - +# CAVEATS: TPM_GPIO_RESET=VULNERABLE (unconfirmed) -- GPIO lock missing, attack not hardware-tested +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. export CONFIG_COREBOOT=y export CONFIG_COREBOOT_VERSION=dasharo_msi_z690 export CONFIG_LINUX_VERSION=6.1.8 diff --git a/boards/UNTESTED_msi_z690a_ddr5/UNTESTED_msi_z690a_ddr5.config b/boards/UNTESTED_msi_z690a_ddr5/UNTESTED_msi_z690a_ddr5.config index dbc8803c3..7c28027a5 100644 --- a/boards/UNTESTED_msi_z690a_ddr5/UNTESTED_msi_z690a_ddr5.config +++ b/boards/UNTESTED_msi_z690a_ddr5/UNTESTED_msi_z690a_ddr5.config @@ -1,5 +1,6 @@ # MSI PRO Z690-A (DDR5) board configuration - +# CAVEATS: TPM_GPIO_RESET=VULNERABLE (unconfirmed) -- GPIO lock missing, attack not hardware-tested +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. export CONFIG_COREBOOT=y export CONFIG_COREBOOT_VERSION=dasharo_msi_z690 export CONFIG_LINUX_VERSION=6.1.8 diff --git a/boards/UNTESTED_msi_z790p_ddr4/UNTESTED_msi_z790p_ddr4.config b/boards/UNTESTED_msi_z790p_ddr4/UNTESTED_msi_z790p_ddr4.config index 7b67bf351..829a8389a 100644 --- a/boards/UNTESTED_msi_z790p_ddr4/UNTESTED_msi_z790p_ddr4.config +++ b/boards/UNTESTED_msi_z790p_ddr4/UNTESTED_msi_z790p_ddr4.config @@ -1,5 +1,6 @@ # MSI PRO Z790-P DDR4 board configuration - +# CAVEATS: TPM_GPIO_RESET=VULNERABLE (unconfirmed) -- GPIO lock missing, attack not hardware-tested +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. export CONFIG_COREBOOT=y export CONFIG_COREBOOT_VERSION=dasharo_msi_z790 export CONFIG_LINUX_VERSION=6.1.8 diff --git a/boards/UNTESTED_nitropad-ns50/UNTESTED_nitropad-ns50.config b/boards/UNTESTED_nitropad-ns50/UNTESTED_nitropad-ns50.config index f2587134e..cc4951a5c 100644 --- a/boards/UNTESTED_nitropad-ns50/UNTESTED_nitropad-ns50.config +++ b/boards/UNTESTED_nitropad-ns50/UNTESTED_nitropad-ns50.config @@ -1,5 +1,6 @@ # Nitrokey Nitropad NS51 board configuration -# Note: for reference, other GOP enabled FB board is librem_11 +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # # Docs: # Dissassembly and Recovery: https://docs.dasharo.com/unified/novacustom/recovery/#ns5x7x-12th-gen diff --git a/boards/UNTESTED_talos-2/UNTESTED_talos-2.config b/boards/UNTESTED_talos-2/UNTESTED_talos-2.config index d8dcf8e39..cc486fa84 100644 --- a/boards/UNTESTED_talos-2/UNTESTED_talos-2.config +++ b/boards/UNTESTED_talos-2/UNTESTED_talos-2.config @@ -1,5 +1,8 @@ # Configuration for a Talos 2 running Qubes and other OSes # The board uses BE coreboot and LE Linux kernel and initrd +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- POWER9 platform, not Intel +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_TARGET_ARCH=ppc64 export CONFIG_COREBOOT=y diff --git a/boards/librem_11/librem_11.config b/boards/librem_11/librem_11.config index e8a78fd78..957e8aa56 100644 --- a/boards/librem_11/librem_11.config +++ b/boards/librem_11/librem_11.config @@ -1,5 +1,7 @@ # Configuration for librem_11 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=NOT_APPLICABLE -- No TPM hardware (CONFIG_NO_TPM=y); uses ROM-hash HOTP +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_11.config export CONFIG_COREBOOT=y diff --git a/boards/librem_14/librem_14.config b/boards/librem_14/librem_14.config index a7a36157f..ad44492c1 100644 --- a/boards/librem_14/librem_14.config +++ b/boards/librem_14/librem_14.config @@ -1,5 +1,7 @@ # Configuration for a librem 14 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_14.config export CONFIG_COREBOOT=y diff --git a/boards/librem_l1um_v2/librem_l1um_v2.config b/boards/librem_l1um_v2/librem_l1um_v2.config index c1a70babd..9e41b4b3b 100644 --- a/boards/librem_l1um_v2/librem_l1um_v2.config +++ b/boards/librem_l1um_v2/librem_l1um_v2.config @@ -1,5 +1,7 @@ # Configuration for librem_l1um_v2 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_l1um_v2.config export CONFIG_COREBOOT=y diff --git a/boards/librem_mini/librem_mini.config b/boards/librem_mini/librem_mini.config index 72ba6e4a5..8724adf25 100644 --- a/boards/librem_mini/librem_mini.config +++ b/boards/librem_mini/librem_mini.config @@ -1,5 +1,7 @@ # Configuration for a librem mini CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=NOT_APPLICABLE -- No TPM hardware (CONFIG_NO_TPM=y); uses ROM-hash HOTP +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_mini.config export CONFIG_COREBOOT=y diff --git a/boards/librem_mini_v2/librem_mini_v2.config b/boards/librem_mini_v2/librem_mini_v2.config index 947145fad..2579b62fd 100644 --- a/boards/librem_mini_v2/librem_mini_v2.config +++ b/boards/librem_mini_v2/librem_mini_v2.config @@ -1,5 +1,7 @@ # Configuration for a librem mini v2 CONFIG_LINUX_CONFIG=config/linux-librem_common-6.1.8.config +# CAVEATS: TPM_GPIO_RESET=NOT_APPLICABLE -- No TPM hardware (CONFIG_NO_TPM=y); uses ROM-hash HOTP +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. CONFIG_COREBOOT_CONFIG=config/coreboot-librem_mini_v2.config export CONFIG_COREBOOT=y diff --git a/boards/msi_z790p_ddr5/msi_z790p_ddr5.config b/boards/msi_z790p_ddr5/msi_z790p_ddr5.config index 91d71eed9..63c91439f 100644 --- a/boards/msi_z790p_ddr5/msi_z790p_ddr5.config +++ b/boards/msi_z790p_ddr5/msi_z790p_ddr5.config @@ -1,5 +1,6 @@ # MSI PRO Z790-P (DDR5) board configuration - +# CAVEATS: TPM_GPIO_RESET=VULNERABLE (unconfirmed) -- GPIO lock missing, attack not hardware-tested +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. export CONFIG_COREBOOT=y export CONFIG_COREBOOT_VERSION=dasharo_msi_z790 export CONFIG_LINUX_VERSION=6.1.8 diff --git a/boards/novacustom-nv4x_adl/novacustom-nv4x_adl.config b/boards/novacustom-nv4x_adl/novacustom-nv4x_adl.config index 55949736a..f9056c823 100644 --- a/boards/novacustom-nv4x_adl/novacustom-nv4x_adl.config +++ b/boards/novacustom-nv4x_adl/novacustom-nv4x_adl.config @@ -1,5 +1,6 @@ # NovaCustom NV4x 12th Gen (nv40pz: Alder Lake) board configuration -# Note: for reference, other GOP enabled FB board is librem_11 +# CAVEATS: TPM_GPIO_RESET=VULNERABLE -- TOTP/HOTP secret extractable, DUK with passphrase safe +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. # # Docs: # Dissassembly and Recovery: https://docs.dasharo.com/unified/novacustom/recovery/#12th-gen diff --git a/boards/novacustom-v540tu/novacustom-v540tu.config b/boards/novacustom-v540tu/novacustom-v540tu.config index 75033a92c..8cf4e7628 100644 --- a/boards/novacustom-v540tu/novacustom-v540tu.config +++ b/boards/novacustom-v540tu/novacustom-v540tu.config @@ -12,7 +12,9 @@ # # DISCLAIMER: Meteor Lake (Intel Gen 14) is not supposed to support s3 but coincidently does. In case s3 is broken, user must configure settings to not suspend or otherwise enable # ME/CSME for s0ix to work (unsupported by QubesOS when writing those lines) or use Hibernate (Not supported by QubesOS either) - +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- PCR GPIO lock Kconfig selected but per-pad enforcement unconfigured in board GPIO tables; GPIO PLTRST# assertion does not apply to eSPI-connected TPMs on this platform +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. export CONFIG_COREBOOT=y export CONFIG_COREBOOT_VERSION=dasharo_v56 export CONFIG_DASHARO_EC=y diff --git a/boards/novacustom-v560tu/novacustom-v560tu.config b/boards/novacustom-v560tu/novacustom-v560tu.config index bd3976a1b..280c86018 100644 --- a/boards/novacustom-v560tu/novacustom-v560tu.config +++ b/boards/novacustom-v560tu/novacustom-v560tu.config @@ -12,7 +12,9 @@ # # DISCLAIMER: Meteor Lake (Intel Gen 14) is not supposed to support s3 but coincidently does. In case s3 is broken, user must configure settings to not suspend or otherwise enable # ME/CSME for s0ix to work (unsupported by QubesOS when writing those lines) or use Hibernate (Not supported by QubesOS either) - +# +# CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- PCR GPIO lock Kconfig selected but per-pad enforcement unconfigured in board GPIO tables; GPIO PLTRST# assertion does not apply to eSPI-connected TPMs on this platform +# See doc/TPM_GPIO_Reset_Vulnerability.md for details. export CONFIG_COREBOOT=y export CONFIG_COREBOOT_VERSION=dasharo_v56 export CONFIG_DASHARO_EC=y diff --git a/doc/BOARDS_AND_TESTERS.md b/doc/BOARDS_AND_TESTERS.md index 56a25a6ce..f829962c5 100644 --- a/doc/BOARDS_AND_TESTERS.md +++ b/doc/BOARDS_AND_TESTERS.md @@ -1,49 +1,138 @@ General information == -- **Intel CPU Generations:** [List of Intel processors](https://en.wikipedia.org/wiki/List_of_Intel_processors) - - **End of Servicing Updates (ESU Date)** [ESU table for Intel processors](https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html) -- **AMD CPU Generations:** [List of AMD processors](https://en.wikipedia.org/wiki/AMD_processors) -- **Transient CPU Vulnerabilities:** [Transient execution CPU vulnerability](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability) - -**Note (as of 2025-05-29):** -- Intel CPUs from the 1st to 7th generations (Nehalem through Kaby Lake) have reached End-of-Life (EOL) status and no longer receive microcode updates. Consequently, these processors remain vulnerable to Spectre Variant 2 (CVE-2017-5715) and related speculative execution vulnerabilities. -- Some 8th generations (Kaby Lake Refresh) also reached EOL per Intel ESU. -- **Those boards names were renamed with EOL_ preceding their board names for users to be hinted by this at download/compilation/testing time** - -While software-based mitigations like Retpoline can reduce exposure to certain speculative execution attacks, their effectiveness is limited without corresponding microcode updates. Therefore, systems utilizing these older CPUs should be considered inherently vulnerable to Spectre Variant 2 and similar threats. - -Only mitigation is to make sure no secret is present in memory (trusted workflow) in parallel of untrusted workflows. -- This implies a single trusted workflow per boot session, ideally without any secrets remaining in memory—for example, running Tails from a live CD without providing it with any disk decryption passphrase. - - Poper OPSEC when running Tails: https://www.anarsec.guide/posts/tails - - The moment a secret resides in memory (e.g., a passphrase or private document), minimize its exposure by limiting its duration—reboot before switching tasks. - - Always prioritize security over convenience. When in doubt, reboot. - - Proper OPSEC for Memory use on QubesOS: https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use - - Use disposable qubes as if you were running Tails: use distinct disposable qubes and for really short lived tasks: always consider disk decryption key in memory at risk! -**On systems affected by QSB-107 and lacking updated microcode, [any untrusted application running in a qube could potentially exfiltrate sensitive memory content at a rate of as fast as 5.6 KiB/s.](https://comsec.ethz.ch/research/microarch/branch-privilege-injection)** - - -Live list of community supported platform testers per last coreboot/linux version bump -== - -Heads is a community project, where boards under boards/* need to be tested by board owners when coreboot/linux version bumps happen prior of a Pull Request (PR) merge. -This list will be maintained per coreboot/linux version bumps PRs. - -Please see boards/BOARD_NAME/BOARD_NAME.config for HCL details. - ----- - -As per tracking issue for board testers: https://github.com/linuxboot/heads/issues/692, currently built CircleCI boards ROMs are: +[Intel](https://en.wikipedia.org/wiki/List_of_Intel_processors) and +[AMD](https://en.wikipedia.org/wiki/List_of_AMD_processors) CPU generations; +[Transient execution CPU vulnerability](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability). + +"ESU" means "End of Servicing Updates" -- the date after which Intel stops +releasing microcode for a CPU generation; newly discovered vulnerabilities on +past-ESU generations remain unpatched. The `EOL_` prefix in board directories +indicates ended microcode servicing. For future ESU dates refer to: +- **Intel:** [ESU policy](https://www.intel.com/content/www/us/en/support/topics/support-and-servicing-for-processors.html) | [microcode releases](https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases) +- **AMD:** [linux-firmware microcode history](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amd-ucode/) +- **IBM POWER9:** [End of Standard Service announcement](https://public.dhe.ibm.com/systems/support/planning/notices/September.12.2024.Announcement.Power9.pdf) (January 31, 2026) + +## Per-board EOL/ESU status + +The Last Microcode column links to the [Intel microcode releases page](https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases). +Dates below are as of the document's last update and may be stale. + +**EOL boards** (`EOL_` prefix present): + +| Board | Gen | Code Name | ESU Date | Last Microcode | +|---|---|---|---|---| +| `EOL_t420` | 2nd | Sandy Bridge | No official ESU | 2019-05-14 | +| `EOL_x220` | 2nd | Sandy Bridge | No official ESU | 2019-05-14 | +| `EOL_t430` | 3rd | Ivy Bridge | No official ESU | 2019-05-14 | +| `EOL_w530` | 3rd | Ivy Bridge | No official ESU | 2019-05-14 | +| `EOL_x230` | 3rd | Ivy Bridge | No official ESU | 2019-05-14 | +| `EOL_t530` | 3rd | Ivy Bridge | No official ESU | 2019-05-14 | +| `EOL_optiplex-7010_9010` | 3rd | Ivy Bridge | No official ESU | 2019-05-14 | +| `EOL_z220-cmt` | 3rd | Ivy Bridge | No official ESU | 2019-05-14 | +| `EOL_t440p` | 4th | Haswell | Jun 30, 2021 | 2021-06 | +| `EOL_w541` | 4th | Haswell | Jun 30, 2021 | 2021-06 | +| `EOL_librem_l1um` | 5th | Broadwell | Jun 30, 2021 | 2020-06 | +| `EOL_librem_13v2` | 6th | Skylake | Sep 30, 2022 | 2022-11 | +| `EOL_librem_15v3` | 6th | Skylake | Sep 30, 2022 | 2022-11 | +| `EOL_m900_tower` | 6th | Skylake | Sep 30, 2022 | 2022-11 | +| `EOL_librem_13v4` | 7th | Kaby Lake | Mar 31, 2024 | 2024-03 | +| `EOL_librem_15v4` | 7th | Kaby Lake | Mar 31, 2024 | 2024-03 | +| `EOL_t480` | 8th | Kaby Lake-R | Mar 31, 2026 ¹ | 2024-03 | +| `EOL_t480s` | 8th | Kaby Lake-R | Mar 31, 2026 ¹ | 2024-03 | + +¹ KBL-R falls under Whiskey Lake ESU (Mar 31, 2026); also classified under Coffee Lake ESU (Jun 30, 2025). Both dates have passed. + +| `librem_l1um_v2` | 9th | Coffee Lake Refresh | Jun 30, 2026 | Not in Feb 2026+ | +| `librem_mini` | 8th | Whiskey Lake | Mar 31, 2026 | Not in Feb 2026+ | +| `UNTESTED_talos-2` | POWER9 | Talos II (IBM) | Jan 31, 2026 ² | Feb 2024 ² | + +² IBM End of Standard Service for POWER9. Last Raptor firmware release: February 2024. + +**Active boards** (ESU not yet reached; no `EOL_` prefix): + +| Board | Gen | Code Name | ESU Date | Last Microcode | +|---|---|---|---|---| +| `librem_14` | 10th | Comet Lake | Jun 30, 2027 | 2025-05 ³ | +| `librem_mini_v2` | 10th | Comet Lake | Jun 30, 2027 | 2025-05 ³ | +| `librem_11` | Atom | Jasper Lake | TBD | TBD | +| `UNTESTED_nitropad-ns50` | 12th | Alder Lake | Active | 2026-02 | +| `novacustom-nv4x_adl` | 12th | Alder Lake | Active | 2026-02 | +| `UNTESTED_msi_z690a_ddr4` | 12th | Alder Lake | Active | 2026-02 | +| `UNTESTED_msi_z690a_ddr5` | 12th | Alder Lake | Active | 2026-02 | +| `msi_z790p_ddr5` | 13th | Raptor Lake | Active | 2026-05 | +| `UNTESTED_msi_z790p_ddr4` | 13th | Raptor Lake | Active | 2026-05 | +| `novacustom-v540tu` | Core Ultra S1 | Meteor Lake | Active | 2026-05 | +| `novacustom-v560tu` | Core Ultra S1 | Meteor Lake | Active | 2026-05 | + +³ Comet Lake ESU runs through Jun 30, 2027. Check the +[Intel microcode releases page](https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases) +for recent updates. + +**Formerly supported** (`unmaintained_boards/*/`; reference only): + +| Board | Gen | Code Name | ESU Date | Last Microcode | +|---|---|---|---|---| +| KGPE-D16 | AMD Family 15h | Bulldozer | No AMD ESU | 2018-05 (dropped in coreboot 4.12) | + +KGPE-D16 is the last fully blob-free **x86** platform (Talos II is the last +fully blob-free platform overall, on POWER9). AMD ceased Family 15h microcode +in 2018; removed from upstream coreboot in 4.12 (2019). The Dasharo fork was +abandoned August 2025. An independent community port (15h.org, October 2025) +exists but is not part of upstream coreboot. + +### Mitigation + +Spectre Variant 2 (CVE-2017-5715) and related speculative execution +vulnerabilities are unpatched on any board past its ESU date. Retpoline and +similar software mitigations have limited effectiveness without microcode +updates. On EOL platforms, run a single trusted workflow per boot session +and reboot before switching tasks. + +See the [Heads threat model](https://osresearch.net/Heads-threat-model/#mitigation-on-eol-platforms) +for detailed guidance including Tails OPSEC, QubesOS memory management, and +QSB-107 exposure rates. + +## TPM GPIO Reset Vulnerability + +Many Intel platforms are vulnerable to a TPM GPIO reset bypass +([mkukri.xyz, 2024](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html)). +See the [Heads Wiki Threat Model](https://github.com/linuxboot/heads-wiki/blob/master/About/Heads-threat-model.md) +for per-platform status and mitigation. Test with: + +```bash +tpm-gpio-detect 2>&1 | tee /media/tpm-gpio-detect.log +tpm-gpio-assert 2>&1 | tee /media/tpm-gpio-assert.log +``` +The TPM Reset clears all PCRs to zero. A subsequent attacker would need + to replay known PCR measurements to reconstruct the sealed state and + extract TOTP/HOTP shared secrets -- this PoC proves the reset is possible + but does not perform PCR replay. + +The TPM Disk Unlock Key with passphrase is **not affected** -- the +passphrase is required regardless of PCR state. TPMTOTP/HOTP remote +attestation **is affected** -- the shared secret at NVRAM index 0x4d47 +has no passphrase, enabling unseal with forged PCRs. + +The fix must come from coreboot. Tracked at [coreboot ticket #576](https://ticket.coreboot.org/issues/576) +and [coreboot patch series](https://review.coreboot.org/q/topic:%22intel_gpio_lock%22). + +## Board Testers + +Boards under `boards/*` must be tested by listed owners for coreboot/linux +version bumps. This file is the primary board tester registry. +To be added or removed as a tester, comment on [issue #692](https://github.com/linuxboot/heads/issues/692). +For HCL details: `boards/BOARD_NAME/BOARD_NAME.config`. Laptops == -xx20 (Sandy Bridge: Intel 2nd Gen CPU) +xx20 (Sandy Bridge, 2nd Gen -- EOL) === - [ ] t420 (xx20): @notgivenby @alexmaloteaux @akfhasodh @doob85 - [ ] x220 (xx20): @srgrint @Thrilleratplay -xx30 (Ivy Bridge: Intel 3rd Gen CPU) +xx30 (Ivy Bridge, 3rd Gen -- EOL) === - [ ] t430 (xx30): @notgivenby @nestire @Thrilleratplay @alexmaloteaux @lsafd @bwachter(iGPU maximized) @shamen123 @eganonoa(iGPU) @nitrosimon @jans23 @icequbes1 (iGPU) @weyounsix (t430-dgpu) - [ ] w530 (xx30): @eganonoa @zifxify @weyounsix (dGPU: w530-k2000m) @jnscmns (dGPU K1000M) @computer-user123 (w530 / w530 k2000: prefers iGPU) @tlaurion @@ -51,47 +140,53 @@ xx30 (Ivy Bridge: Intel 3rd Gen CPU) - [ ] x230-fhd/edp variant: @n4ru @computer-user123 (nitro caster board) @Tonux599 @househead @pcm720 (eDP 4.0 board and 1440p display) @doob85 - [ ] t530 (xx30): @fhvyhjriur @3hhh (See: https://github.com/linuxboot/heads/issues/1682) -xx4x (Haswell: Intel 4th Gen CPU) +ThinkCentre (Skylake, 6th Gen Desktop -- EOL) +=== +- [ ] M900 Tower: @notgivenby + +xx4x (Haswell, 4th Gen -- EOL) === - [ ] t440p: @MattClifton76 @fhvyhjriur @ThePlexus @srgrint @akunterkontrolle @rbreslow -- [ ] w541 (similar of t440p): @gaspar-ilom @ResendeGHF +- [ ] w541 (similar to t440p): @gaspar-ilom @ResendeGHF -xx8x (Kaby Lake Refresh: Intel 8th Gen Mobile : ESU ended 12/31/2024) +xx8x (Kaby Lake Refresh, 8th Gen Mobile -- EOL) === - [ ] t480: @gaspar-ilom @doritos4mlady @MattClifton76 @notgivenby @akunterkontrolle @nestire (Nitrokey) - [ ] t480s: @thickfont @kjkent @HarleyGodfrey @nestire (Nitrokey) Librem === -- [ ] Librem 13v2 (Sky Lake: Intel 6th Gen CPU): @JonathonHall-Purism -- [ ] Librem 15v3 (Sky Lake: Intel 6th Gen CPU): @JonathonHall-Purism -- [ ] Librem 15v4 (Kaby Lake: Intel 7th Gen CPU): @JonathonHall-Purism -- [ ] Librem 13v4 (Kaby Lake: Intel 7th Gen CPU): @JonathonHall-Purism -- [ ] Librem 14 (Comet Lake: Intel 10th Gen CPU): @JonathonHall-Purism -- [ ] Librem 11 (Jasper Lake: Intel 11th Gen Atom CPU): @JonathonHall-Purism +All EOL unless marked Active. +- [ ] Librem 13v2 (Skylake, 6th Gen): @JonathonHall-Purism +- [ ] Librem 15v3 (Skylake, 6th Gen): @JonathonHall-Purism +- [ ] Librem 15v4 (Kaby Lake, 7th Gen): @JonathonHall-Purism +- [ ] Librem 13v4 (Kaby Lake, 7th Gen): @JonathonHall-Purism +- [ ] Librem 14 (Comet Lake, 10th Gen -- Active): @JonathonHall-Purism +- [ ] Librem 11 (Jasper Lake, Atom -- Active): @JonathonHall-Purism Clevo === -- [ ] Nitropad NS50 (Alder Lake: Intel 12th Gen CPU): @daringer -- [ ] Novacustom NV4x (Alder Lake: Intel 12th Gen CPU): @tlaurion @daringer -- [ ] Novacustom v540tu (Meteor Lake: Intel Core Ultra 7 155H, Core Ultra Series 1 – 14th Gen Mobile): @tlaurion @daringer @mkopec -- [ ] Novacustom v560tu (Meteor Lake: Intel Core Ultra 7 155H, Core Ultra Series 1 – 14th Gen Mobile): @tlaurion @daringer @mkopec - +All Active. +- [ ] Nitropad NS50 (Alder Lake, 12th Gen): @daringer +- [ ] Novacustom NV4x (Alder Lake, 12th Gen): @tlaurion @daringer +- [ ] Novacustom v540tu (Meteor Lake, Core Ultra S1): @tlaurion @daringer @mkopec +- [ ] Novacustom v560tu (Meteor Lake, Core Ultra S1): @tlaurion @daringer @mkopec Desktops / Servers == -- [ ] Optiplex 7010/9010 SFF/DT (Ivy Bridge: Intel 3rd Gen CPU): @tlaurion(owns DT variant) -- [ ] HP Z220 CMT (Ivy Bridge: Intel 3rd Gen CPU): @d-wid -- [ ] KGPE-D16 (Bulldozer: AMD Family 15h CPU) – dropped in coreboot 4.12: @arhabd @Tonux599 @zifxify -- [ ] Librem L1UM v1 (Broadwell: Intel 5th Gen CPU): @JonathonHall-Purism -- [ ] Librem L1UM v2 (Coffee Lake: Intel 9th Gen CPU): @JonathonHall-Purism -- [ ] Librem mini v1 (Whiskey Lake: Intel 8th Gen CPU : ESU ends 03/31/2026): @JonathonHall-Purism -- [ ] Librem mini v2 (Comet Lake: Intel 10th Gen CPU): @JonathonHall-Purism -- [ ] Talos II (Power9, PPC64LE): @tlaurion (became untested, low community interest despite large investment) - -MSI +All EOL unless marked Active. +- [ ] Optiplex 7010/9010 SFF/DT (Ivy Bridge, 3rd Gen): @tlaurion(owns DT variant) +- [ ] HP Z220 CMT (Ivy Bridge, 3rd Gen): @d-wid +- [ ] KGPE-D16 (AMD Family 15h): @arhabd @Tonux599 @zifxify +- [ ] Librem L1UM v1 (Broadwell, 5th Gen): @JonathonHall-Purism +- [ ] Librem L1UM v2 (Coffee Lake, 9th Gen): @JonathonHall-Purism +- [ ] Librem mini v1 (Whiskey Lake, 8th Gen): @JonathonHall-Purism +- [ ] Librem mini v2 (Comet Lake, 10th Gen -- Active): @JonathonHall-Purism +- [ ] Talos II (POWER9, PPC64LE): @tlaurion (became untested, low community interest despite large investment) + +MSI (Alder/Raptor Lake — Active) --- -- [ ] MSI PRO Z690-A (WIFI) (DDR4): **None** - Board is untested. -- [ ] MSI PRO Z690-A (WIFI) (DDR5): **None** - Board is untested. -- [ ] MSI PRO Z790-P (WIFI) (DDR4): **None** - Board is untested. -- [ ] MSI PRO Z790-P (WIFI) (DDR5): @Tonux599 +- [ ] MSI PRO Z690-A (WIFI) (DDR4): **None** - Board is untested. (Active, Alder Lake 12th Gen) +- [ ] MSI PRO Z690-A (WIFI) (DDR5): **None** - Board is untested. (Active, Alder Lake 12th Gen) +- [ ] MSI PRO Z790-P (WIFI) (DDR4): **None** - Board is untested. (Active, Raptor Lake 13th Gen) +- [ ] MSI PRO Z790-P (WIFI) (DDR5): @Tonux599 (Active, Raptor Lake 13th Gen) diff --git a/doc/TPM_GPIO_Reset_Approaches.md b/doc/TPM_GPIO_Reset_Approaches.md new file mode 100644 index 000000000..90e7578d2 --- /dev/null +++ b/doc/TPM_GPIO_Reset_Approaches.md @@ -0,0 +1,441 @@ +# TPM GPIO Reset Attack -- Approaches Exhausted on Intel ADL-P (NovaCustom NV4x) + +This document chronicles every approach tried during development of the TPM GPIO +reset Proof-of-Concept for Intel ADL-P (Alder Lake mobile, NovaCustom NV4x) +and the broader family of affected platforms. + +## Background + +The TPM GPIO reset attack, disclosed by Mate Kukri in June 2024, exploits a +design flaw in Intel PCH platforms where the PLTRST# (Power Loss Timer Reset) +signal driving the discrete TPM is connected through a multi-function GPIO pad. +On vulnerable platforms, this pad can be reprogrammed from native function +(LPC/eSPI/SPI output) to GPIO output mode, allowing an attacker to assert a +hardware reset of the TPM, clear its PCRs, and then forge measurement values +to unseal sealed secrets. + +The attack relies on three conditions: +1. The PLTRST# pad is part of a GPIO community, not a dedicated pin. +2. The GPIO pad configuration lock is NOT set by firmware. +3. The PLTRST# assertion mechanism actually works when the pad is toggled. + +Condition 3 proved unexpectedly difficult on ADL-P. This document explains why. + +--- + +## 1. What We Verified (from coreboot source code) + +### 1.1 Register Addresses Verified Against coreboot 26.06 + +All register addresses were cross-checked against coreboot 26.06 source code +and the kukrimate/tpm-gpio-fail reference implementation. Bit field definitions +(PADRSTCFG, mode mask) were verified against the Linux kernel pinctrl-intel.c. + +See `tpm-gpio-detect` for the authoritative per-platform +register map: + +- Header comments (lines 50-76): port, pad index, PAD_CFG_BASE, lock offset + per platform family (CNP-LP, SPT/KBP, ADL-P, ADL-S, RPL-S, MTL). +- `detect_platform()` case statement (lines 260-368): PCI device ID to + platform parameter mapping. +- `calculate_registers()` (lines 533-620): full address computation from + PCR_BASE, community port, pad index, and PAD_CFG_BASE, including the + per-pad register layout (2 vs 4 DWORDS per pad) for each generation. + +Note: Intel doc 834810 does not cover pre-Tiger Lake platforms. SPT/KBP +(Skylake/Kaby Lake) PADCFGLOCK offsets (0xA8 per kukri) have no public +Intel verification. + +Note: CML-U (0x066x) and some CML-U steppings in the 0x9d8* range have +PADCFGLOCK at 0x88. Not all 0x9d8* devices have lock registers -- verify +per-stepping. CNP-LP proper (0x9d84) is confirmed to lack the register. + +### 1.2 Platform Detection via PCI Device ID + +Platform detection uses the ISA/LPC bridge (class 0x0601, device 00:1f.0 on Intel). +PCI device IDs map to PCH families as documented in the script's `detect_platform()` +function. This is reliable across all Linux kernels and does not depend on DMI data +or board config. + +**Definitive results from NV4x ADL-P testing (debug mode, 2026-07-22):** + +| Test | Result | +|---|---| +| DW0 original value | `0x00040040` (mode=GPIO, TX=0, PADRSTCFG=PWROK) | +| PADCFGLOCK (0xFD6E0080) | `0x00000000` — NOT locked | +| PADCFGLOCKTX (0xFD6E0084) | `0x00000000` — NOT locked | +| Write 0x40000401 (NF1) | Readback `0x01040040`, mode=0 — **mode bits [13:10] locked** | +| Write 0x80000000 (kukrimate) | Readback `0x00000080` — **verified** (bit 31 set, TX=0) | +| Write 0x80000001 (TX=1) | Readback `0x03000080`, TX=0 -- PADRSTCFG side effect \\* | +| Write 0x80000000 (TX=0) | Readback `0x00000080` — verified | +| `tpmr.sh shutdown` | Success | +| `tpm2 startup -c` | **Success** (exit 0, stderr clean) | +| `tpmr.sh startsession` | **Success** (encrypted sessions recreated) | +| `/sys/class/tpm/tpm0/pcrs` | **NOT FOUND** — kernel TPM driver did not detect bus reset | +| `pcrs()` / `tpm2 pcrread sha256` | Hangs after GPIO assertion | +| `tpm2 pcrread sha256:0` | Sometimes succeeds, sometimes hangs | + +The ADL-P `tpm2 pcrread sha256` hang (observed during all-PCR reads) is a **SEPARATE issue** from the GPIO manipulation — the hang occurs even without GPIO toggle. This may be a TPM driver / kernel issue specific to ADL-P mobile, not a consequence of PLTRST# assertion behavior. + +\\* `0x03000080` has bit 7, bit 24, and bit 25 set — these do not map to any defined +DW0 register field on ADL-P. PADCFGLOCKTX reads as `0x00000000` (unlocked), meaning +the TX bit should be writable per coreboot GPIO documentation. The anomalous readback +may be a PCR sideband artifact rather than a definitive TX lock. **Cannot confirm +whether TX toggle generates a PLTRST# edge without physical scope measurement.** + +The anomalous readback 0x03000080 on ADL-P TX toggle contains bits 7, 24, and 25 +that do not map to any defined DW0 field. This may indicate a PCR sideband +read-back artifact, an undocumented hardware state register, or a die-specific +side-effect. Follow-up with a logic analyzer on the physical PLTRST# pin is +needed to determine whether the pad state actually changed. + +**Key conclusion:** After the full shutdown→GPIO→startup sequence, the kernel TPM +driver does NOT detect a bus reset (`/sys/class/tpm/tpm0/pcrs` never appears). +PCRs are cleared by `tpm2 startup -c` alone. Whether the GPIO manipulation +contributed to the reset cannot be determined from software diagnostics +alone — a logic analyzer on the LPC/eSPI reset line is needed. + +### 1.3 PADCFGLOCK Registers Confirmed Accessible + +PADCFGLOCK and PADCFGLOCKTX registers are read/writable via `/dev/mem` on ADL-P +when `CONFIG_STRICT_DEVMEM=n` (Heads default). + +See `tpm-gpio-detect and tpm-gpio-assert C binaries` for per-platform lock register +addresses: the `_get_lock_base()` helper function (lines 853-866) maps each +PCH family to its PADCFGLOCK offset, and `check_lock_registers()` (lines +1062-1099) performs the read/check at runtime. + +NV4x ADL-P readings: PADCFGLOCK=0x00010203 (bits 0,8,17 set; GPP_B13 bit 13 +NOT set), PADCFGLOCKTX=0x00000000. Pad is NOT locked. + +### 1.4 GPIO Lock Status per Dasharo/Purism Forks + +See `doc/TPM_GPIO_Reset_Vulnerability.md` section "coreboot GPIO Lock Status +by Platform Generation" for per-platform Kconfig selection, code paths, and +non-functional lock status analysis. Key findings specific to NV4x: + +- Dasharo fork (NV4x/NS50/Z790-P): SBI lock method compiled but never called + because no board GPIO table entries use `PAD_CFG_LOCK`. Pad is NOT locked. +- Purism fork (Librem 14, Tiger Lake): No GPIO lock Kconfig selected, no + `pad_cfg_lock_offset`. Pad is NOT locked. + +**Important caveat:** All Dasharo fork GPIO lock analysis is based on build +tree inspection (Kconfig, source code, FSP UPDs). No Dasharo firmware image +with PADCFGLOCK actually set has been tested on hardware. The claim that +"adding PAD_CFG_NF_LOCK to board GPIO tables would lock GPP_B13" is theoretical. + +The Star Labs PchUnlockGpioPads fix (commit 06f3c07, patch 93422) is described +in `doc/TPM_GPIO_Reset_Vulnerability.md` (see "Upstream Tracking"). + +--- + +## 2. Approaches Attempted (in Chronological Order) + +### Approach 1: GPIO Pad Reprogramming (Native -> GPIO Output -> Toggle -> Restore) + +**What we did:** Read DW0/DW1 of GPP_B13 via `/dev/mem`, save originals, write +0x80000000 to DW0 (GPIO output + bit 31), write 0 to DW1, wait 1s, restore +originals. See `assert_pltrst()` in `tpm-gpio-detect and tpm-gpio-assert C binaries` for +the exact implementation. + +**Result on NV4x (ADL-P):** +- DW0 write verified by readback (LE bytes "00000080" returned). +- Pad transitioned to GPIO mode (confirmed by mode bits in readback). +- PCR 2 did NOT clear -- remained non-zero after the toggle. +- `/sys/class/tpm/tpm0/pcrs` NOT FOUND -- kernel TPM driver detected no bus reset. + +**Why it failed:** Changing DW0 mode bits does not drive PLTRST# on the +electrical pin on ADL-P (confirmed: NF1->GPIO transition clear PCRs on NV4x). +this PCH die. The kukrimate reference implementation (`inteltool.c`) does NOT +include ADL-P device IDs and was not tested by the original researcher. + +### Approach 2: Kukrimate-Style Direct Register Write (0x80000000 to DW0) + +**What we did:** Same as Approach 1 but following kukrimate's inteltool.c precisely +(save DW0/DW1, write 0x80000000, wait, write 0 to DW1, restore). + +**Result on NV4x:** Identical to Approach 1 -- write verified, PCR 2 still non-zero. + +**Why it failed:** The PADRSTCFG field (DW0 bits[31:30]) selects the pad's own reset +trigger source per Linux pinctrl-intel.c (`PADCFG0_RESET_MASK = GENMASK(31,30)`); +it does NOT assert PLTRST# on the output signal. 0x80000000 sets PADRSTCFG=PLTRST +as the pad's reset source, GPIO mode, and TX=0 -- the pad will reset when PLTRST# +is asserted by the PCH, but the pad does not drive PLTRST#. ADL-P uses 4-DWORD +pads; Intel doc 834810 may document this field at a different offset for ADL-P +than for SPT/KBP (2-DWORD) layouts. + +### Approach 3: Dynamic SBREG_BAR Reading via P2SB PCI Config Space + +**What we did:** Attempted to read SBREG_BAR from P2SB (00:1f.1) by unhiding it +and reading BAR0. + +**Result on NV4x:** P2SB is hidden by FSP-S and MASKLOCK'd (bit 8 of BCTRL) -- +writes to unhide are silently ignored. PCI config returns 0xffffffff. + +**Why it failed:** FSP-S locks the P2SB HIDE bit during POST. Hidden devices are +not in the kernel's PCI bus topology. See Section 3.1 for the SBI alternative. + +Hardcoded PCR_BASE values remain reliable: ADL-P mobile=0xFD000000, +ADL-S/RPL-S desktop=0xE0000000, SPT/KBP/CNP-LP=0xFD000000. + +### Approach 4: chipsec Analysis of PCR Access Mechanism + +**What we did:** Analyzed chipsec source code to understand its PCR MMIO access +path and `tpm_gpio_fail` module decision tree. + +**Key finding:** chipsec uses the same hardcoded SBREG_BAR=0xFD000000 and the same +`dd`-style mmap via `/dev/mem`. chipsec would confirm "write succeeded" on NV4x +using the same LE byte readback check we use. chipsec's SBI write solution +(solution 5) was not tested -- P2SB is MASKLOCK'd (see Approach 3). + +### Approach 5: PADCFGLOCK / PADCFGLOCKTX Check + +**What we did:** Read PADCFGLOCK at 0xFD6E0080 to verify whether lock bits +blocked our writes. + +**Result on NV4x:** PADCFGLOCK=0x00010203 (bits 0, 8, 17 set; bit 13/GPP_B13 NOT +set). PADCFGLOCKTX=0x00000000. Pad is NOT locked. + +See `check_lock_registers()` in `tpm-gpio-detect and tpm-gpio-assert C binaries` for +per-platform PADCFGLOCK/PADCFGLOCKTX address calculation and the +`_get_lock_base()` helper for lock offset mapping (lines 853-866). + +### Approach 6: NF1 Mode Forcing (GPIO → NF1 → GPIO+TX=0) + +**What we did:** +On ADL-P, the pad starts in GPIO mode (DW0=0x00040040, mode=0). The kukrimate +0x80000000 write only creates a PLTRST# transition when the pad starts in NF1 +mode. Attempted to force NF1 mode first by writing 0x40000401 (NF1 + TX=deassert ++ DEEP reset): + +1. Save DW0 (GPIO mode). +2. Write 0x40000401 to switch pad to NF1 (reconnects PLTRST# signal). +3. Write 0x80000000 (GPIO+TX=0) — pad transitions NF1→GPIO, creating high→low + edge that asserts PLTRST# on the bus. +4. Sleep 1s. +5. Deassert by writing NF1+TX=1. +6. Restore original. + +**Result on NV4x (ADL-P):** +- NF1 write (0x40000401): readback 0x01040040, **mode=0 (GPIO)** — NF1 switch FAILED. + Mode bits [13:10] are hardware-locked, cannot be changed at runtime. +- 0x80000000 write: verified (readback 0x00000080), mode=0, TX=0. +- Since pad never left GPIO mode, no NF1→GPIO transition occurred, no PLTRST# pulse. +- `tpm2 startup -c` succeeds, `tpmr.sh startsession` succeeds, but `/sys/class/tpm/tpm0/pcrs` not found — kernel did not detect bus reset. + +### Approach 7: TX Bit Toggle (TX=1 → TX=0 When Mode Bits Locked) + +**What we did:** Since mode bits [13:10] are locked, tried toggling only the TX bit +(write 0x80000001 → 0x80000000) to create a falling edge on the pad output. + +**Result on NV4x (ADL-P):** TX=1 write readback was 0x03000080 (anomalous -- bits +7, 24, 25 set but TX=0). TX=0 write verified. PADCFGLOCKTX=0x00000000 (unlocked). +`/sys/class/tpm/tpm0/pcrs` NOT FOUND. Inconclusive without physical scope. + +### Approach 8: kukrimate sysfs PCR Verification + +**What we did:** Used `/sys/class/tpm/tpm0/pcrs` (kukrimate's PCR verification +method) instead of `tpm2 pcrread`. The sysfs pcrs file only appears after the +kernel TPM driver detects a bus reset via `tpm2_auto_startup()`. + +**Result on NV4x (ADL-P):** `/sys/class/tpm/tpm0/pcrs` NOT FOUND after GPIO +assertion. `tpm2 startup -c` succeeds, `tpmr.sh startsession` succeeds, but all +PCR clearing is from `TPM2_Startup(CLEAR)` alone per TCG 2.0 Part 1 Section +12.2.3.2. The kernel driver detected no bus reset. See `post_assertion_cleanup()` +in the script for the sysfs pcrs check logic (lines 1216-1233). + +--- + +## 3. Approaches NOT Attempted (Require NDA, Firmware Changes, or C Compilation) + +### 3.1 P2SB SBI Write + +Would require unhiding P2SB (MASKLOCK'd by FSP-S on ADL-P) and sending +sideband messages through undocumented Intel NDA protocols. Not feasible +without custom firmware. + +### 3.2 CF9 Reset + +Writing to I/O port 0xCF9 reboots the entire system (CPU + chipset), losing +kernel state. The attack requires attacker code to survive the reset for PCR +replay, which CF9 reset prevents. + +### 3.3 Custom Dasharo Build with GPIO Locking Disabled + +GPIO locking is already non-functional on NV4x (see Section 1.4). Disabling +what doesn't work won't help -- the issue is the PLTRST# routing inside the +PCH die, not a lock bit. + +### 3.4 C mmap Test Program + +A C mmap program would not produce different electrical results -- the +register write is verified atomic at the MMIO bus level by readback. The +mechanism barrier is PCH-internal routing, not a tooling limitation. + +--- + +## 4. What Remains Unknown (Requires Community Testing or NDA Documentation) + +### 4.1 Whether the Mechanism Works on Other Platform Families + +See `doc/TPM_GPIO_Reset_Vulnerability.md` section "Per-Platform Feasibility" +for the known status of each PCH generation. The open question is whether the +GPIO pad toggling actually asserts PLTRST# on platforms beyond SPT/KBP +(the only family confirmed working by kukrimate). Desktop PCH implementations +(ADL-S/RPL-S, PCR port 0x6d) may route PLTRST# differently. CNP-LP (T480s) +is UNTESTED. + +### 4.2 Whether C mmap Would Behave Differently + +See Section 3.4. The register write is verified atomic at the MMIO bus level +by readback; a C mmap program is not expected to change the electrical result. + +### 4.3 Whether P2SB SBI Write Would Bypass the Blocking Mechanism + +The SBI write path bypasses the GPIO pad MMIO interface and talks directly +to the PCH sideband fabric. If the GPIO pad MMIO route is blocked by some +internal gating (not a lock register, but a functional block), SBI might +still be able to assert PLTRST#. + +However, this is speculative: +- P2SB is likely MASKLOCK'd (cannot unhide from software). +- Even if unhidden, SBI protocol details are Intel NDA. +- No open-source ADL-P PoC uses SBI for this purpose. + +### 4.4 Intel NDA Documentation Gaps + +The following are documented only in Intel's NDA BIOS Writer's Guide (BWG) +and are not available to the open-source community: +- Complete PLTRST# signal routing within ADL-P PCH dies. +- Sideband fabric message formats for GPIO pad control. +- P2SB MASKLOCK behavior and any known workarounds. + +--- + +## 5. What the C Tools Provide + +The C binaries (`tpm-gpio-detect` and `tpm-gpio-assert`) replace the bash PoC. +They use libpci for PCI access and self-documenting output. + +### 5.1 Vulnerability Classification (3-Tier) + +Classifies per verified Dasharo/Purism fork analysis using a 3-tier system: + +- **TIER 1 -- VULNERABLE (confirmed)**: SPT/KBP (T480, M900, Librem, etc.) + by kukri; ADL-P (NV4x, NS50) by this PoC. Pads unlocked, NF1 mode confirmed, + PCRs cleared to zero on NV4x, attack feasible. + +- **TIER 2 -- VULNERABLE (unconfirmed)**: CNP-LP (T480s), CFL-S, CML-U, TGL. + Pad unlocked, mechanism theoretically works but no hardware test data. + kukri's PoC does not support these PCH families. Community testing needed. + +- **TIER 3 -- VULNERABILITY UNCERTAIN**: RPL-P, ADL-S, RPL-S, ARL-S. + GPIO lock absent; mechanism not confirmed on these PCH dies. + +- **NOT VULNERABLE**: Pre-Skylake (dedicated PLTRST# pin), Meteor Lake + (functional GPIO lock via Kconfig, eSPI-connected TPM). + +### 5.2 TCG Specification Guarantees Underlying the Attack + +See `doc/TPM_GPIO_Reset_Vulnerability.md` section "TPM Reset Scope (per TCG +Specification)" for the full TCG 2.0 Part 1 citations (Sections 4, 12.2.3.2, +27.2.6, 37), volatile vs non-volatile persistence, and the TOTP/HOTP vs DUK +unseal requirements. + +### 5.3 Mitigations + +See [Heads Wiki Threat Model](https://github.com/linuxboot/heads-wiki/blob/master/About/Heads-threat-model.md) for mitigations. + +--- + +## 6. Community Testing Request + +See [Heads Wiki Recovery Shell](https://github.com/linuxboot/heads-wiki/blob/master/Installing-and-Configuring/RecoveryShell.md#tpm-gpio-reset-vulnerability-testing) for testing instructions using the C tools (`tpm-gpio-detect`, `tpm-gpio-assert`). + +--- + +## 7. MTL GPIO Lock Fix Recipe + +Meteor Lake (MTL) requires a different GPIO lock approach than ADL. The +following three coordinated changes are needed: + +### 7.1 Fix PchUnlockGpioPads Logic + +Star Labs identified inverted logic in Alder Lake's `PchUnlockGpioPads` UPD +(commit 06f3c07, in-review patch 93422). The original code had: +```c +PchUnlockGpioPads = lockdown_by_fsp; +``` +This sets the UPD to 0 when coreboot manages lockdown (correct semantic), but +the variable name implies the opposite action. The fix corrects this to +explicitly set the UPD based on whether coreboot or FSP should manage GPIO +pad locking. MTL builds need this fix applied to their FSP integration code. + +### 7.2 Move mainboard_configure_gpios() to Ramstage + +On MTL, `mainboard_configure_gpios()` currently runs in romstage, before FSP-S +initializes the GPIO controller. GPIO pad config registers are not accessible +at this stage. Moving the call to ramstage (after FSP-S runs) ensures pad +config registers are writable when the lock action is applied. + +### 7.3 Add PAD_CFG_NF_LOCK to Board GPIO Tables + +MTL's PCR lock mechanism (`SOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCR`) is +simpler than ADL's SBI method: it uses direct MMIO writes to the PADCFGLOCK +register (no P2SB unhiding needed). Each pad in the board GPIO table that +needs locking must include the `PAD_CFG_NF_LOCK` macro (for native-function +pads like PLTRST#) or `PAD_CFG_LOCK` (for GPIO pads). Without these macros +in the board GPIO table entries, the `gpio_configure_pads()` code path skips +the lock action entirely. + +None of these three changes are applied in current MTL builds (Dasharo or +upstream coreboot). The PCR lock infrastructure compiles but zero pads are +actually locked. Additionally, FSP sets `PchUnlockGpioPads=1` on MTL, +force-unlocking all pads regardless of the board configuration. + +--- + +## Appendix A: Key Register Addresses Reference + +Register definitions are in the C source: +- `detect/platforms/*.c` -- per-platform PCH IDs, GPIO pad lock offsets/ports/bits +- `reset/inteltool.c` -- DW0 assertion offsets and PCH detection switch +- See `modules/tpm-gpio-reset` for build configuration. + +--- + +## Appendix C: References + +- **mkukri.xyz -- "TPM GPIO fail: The Forgotten Bus"** (June 2024) + https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html + Original disclosure with detailed analysis. + +- **kukrimate/tpm-gpio-fail (GitHub)** -- GPL-2.0 PoC tools + https://github.com/kukrimate/tpm-gpio-fail + Contains `detect` and `reset` tools with platform data for SPT, KBP, CNP-H. + +- **coreboot ticket #576** -- "PLTRST_CPU_B pad should be locked to prevent + userspace TPM GPIO reset" + https://ticket.coreboot.org/issues/576 + +- **coreboot patch series** -- "intel_gpio_lock" + https://review.coreboot.org/q/topic:%22intel_gpio_lock%22 + - `#90884` (merged): Set `pad_cfg_lock_offset` in Skylake GPIO communities. + - `#90885` (open): Select `SOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCR` for + Skylake -- tested, does not work on real hardware. + - `#93324` (open): Board-level GPIO lock for Lenovo SKL/KBL ThinkPads + (T480/T480s). Depends on 90885. Stalled on Intel maintainer review + alongside 90885 -- no human Code-Review since June 2026. + - `#93422` (open): Split FSP lockdown (includes Star Labs PchUnlockGpioPads + fix commit 06f3c07, updated July 22 2026). Awaiting Intel maintainer review. + +- **Heads issue #2159** -- TPM GPIO reset attack tracking + https://github.com/linuxboot/heads/issues/2159 + +- **Intel GPIO Best Practices Guide** -- ID 834810 (Public) + Describes pad configuration lock mechanisms and platform-specific register + layouts. Publicly available at intel.com. + +- **chipsec tpm_gpio_fail module** + https://github.com/chipsec/chipsec + Decision tree for evaluating TPM GPIO fail vulnerability on any Intel platform. diff --git a/doc/TPM_GPIO_Reset_Vulnerability.md b/doc/TPM_GPIO_Reset_Vulnerability.md new file mode 100644 index 000000000..d4d6efd28 --- /dev/null +++ b/doc/TPM_GPIO_Reset_Vulnerability.md @@ -0,0 +1,23 @@ +# TPM GPIO Reset Vulnerability + +Disclosed by Mate Kukri, June 2024: . + +## Documentation + +See the [Heads Wiki Threat Model](https://github.com/linuxboot/heads-wiki/blob/master/About/Heads-threat-model.md) for the full vulnerability analysis, per-platform status, and mitigation status. + +## Testing + +The initrd includes two audit tools (when `CONFIG_TPM2_TOOLS=y`): + +```bash +tpm-gpio-detect 2>&1 | tee /media/tpm-gpio-detect.log # audit GPIO lock status +tpm-gpio-assert 2>&1 | tee /media/tpm-gpio-assert.log # assert PLTRST# (destructive) +``` + +## Upstream Tracking + +- [Coreboot ticket #576](https://ticket.coreboot.org/issues/576) — lock PLTRST# pad at boot +- [Coreboot GPIO lock patch series](https://review.coreboot.org/q/topic:%22intel_gpio_lock%22) +- [kukrimate/tpm-gpio-fail](https://github.com/kukrimate/tpm-gpio-fail) — original PoC +- [tlaurion/tpm-gpio-fail](https://github.com/tlaurion/tpm-gpio-fail) — extended fork (14 PCH families) diff --git a/doc/faq.md b/doc/faq.md index 0dca32e7a..3222db1d4 100644 --- a/doc/faq.md +++ b/doc/faq.md @@ -1,122 +1,4 @@ Frequently Asked Questions about Heads === -Why replace UEFI with coreboot? ---- -While Intel's edk2 tree that is the base of UEFI firmware is open source, -the firmware that vendors install on their machines is proprietary and -closed source. Updates for bugs fixes or security vulnerabilities -are at the vendor's convenience; user specific enhancements are likely not -possible; and the code is not auditable. - -UEFI is much more complex than the BIOS that it replaced. It consists of -millions of lines of code and is an entire operating system, -with network device drivers, graphics, USB, TCP, https, etc, etc, etc. -All of these features represents increased "surface area" for attacks, -as well as unnecessary complexity in the boot process. - -coreboot is open source and focuses on just the code necessary to bring -the system up from reset. This minimal code base has a much smaller -surface area and is possible to audit. Additionally, self-help is -possible if custom features are required or if a security vulnerability -needs to be patched. - - -What's wrong with UEFI Secure Boot? ---- -Can't audit it, signing keys are controlled by vendors, -doesn't handle hand off in all cases, depends on possible leaked keys. - - -Why use Linux instead of vboot2? ---- -vboot2 is part of the coreboot tree and is used by Google in the -Chromebook system to provide boot time security by verifying the -hashes on the coreboot payload. This works well for the specialized -Chrome OS on the Chromebook, but is not as flexible as a measured -boot solution. - -By moving the verification into the boot scripts we're able to have -a much flexible verification system and use more common tools like PGP -to sign firmware stages. - - -What about Trusted GRUB? ---- -The mainline grub doesn't have support for TPM and signed kernels, but -there is a Trusted grub fork that does. Due to philosophical differences -the code might not be merged into the mainline. And due to problems -with secure boot (which Trusted Grub builds on), many distributions have -signed insecure kernels that bypass all of the protections secure -boot promised. - -Additionally, grub is closer to UEFI in that it must have device -drivers for all the different boot devices, as well as filesystems. -This duplicates the code that exists in the Linux kernel and has its -own attack surface. - -Using coreboot and Linux as a boot loader allows us to restrict -the signature validation to keys that we control. We also have one code -base for the device drivers in the Linux-as-a-boot-loader as well -as Linux in the operating system. - - -What is the concern with the Intel Management Engine? ---- -"Rootkit in your chipset", "x86 considered harmful", etc - - -How about the other embedded devices in the system? ---- -#goodbios, funtenna, etc. - - -Should we be concerned about the binary blobs? ---- -Maybe. x230 has very few (MRC) since it has native vga init. - - -Why use ancient Thinkpads instead of modern Macbooks? ---- -coreboot support, TPM, nice keyboards, cheap to experiment on. - -How likely are physical presence attacks vs remote software attacks? ---- -Who knows. - - -Defense in depth vs single layers ---- -Yes. - -is it worth doing the hardware modifications? ---- -Depends on your threat model. - - -Should I validate the TPMTOTP on every boot? ---- -Probably. I want to make it also do it at S3. - - -suspend vs shutdown? ---- -S3 is subject to cold boot attacks, although they are harder to -pull off on a Heads system since the boot devices are constrained. - -However, without tpmtotp in s3 it is hard to know if the system is in -a safe state when the xscreensaver lock screen comes up. Is it a fake -to deceive you and steal your login password? Maybe! It wouldn't get -your disk passphrase, which is perhaps an improvement. - - -Disk key in TPM (LUKS TPM Disk Unlock Key) or user passphrase? ---- -Depends on your threat model. With the Disk Unlock Key in the TPM an -attacker would need to have the entire machine (or a backdoor in the TPM) -to get the key and their attempts to unlock it can be rate limited -by the TPM hardware. - -However, this ties the disk to that one machine (without having to -recover and type in the master key), which might be an unacceptable risk -for some users. +See [Heads FAQ](https://osresearch.net/FAQ/) for frequently asked questions. diff --git a/doc/keys.md b/doc/keys.md index d57a80fc9..1f7de8c6f 100644 --- a/doc/keys.md +++ b/doc/keys.md @@ -1,5 +1,7 @@ # Keys and Secrets in Heads +See also: [About/Keys](https://osresearch.net/Keys/) for the narrative system-level key inventory. + Heads uses several distinct secrets and keys, each protecting a different layer of the system. Understanding what each one does helps in choosing appropriate passphrases and in recovery scenarios. diff --git a/doc/security-model.md b/doc/security-model.md index 8d5e630f0..5979db53c 100644 --- a/doc/security-model.md +++ b/doc/security-model.md @@ -5,7 +5,8 @@ established, how integrity is verified at each boot, and how secrets are protected. See also: [architecture.md](architecture.md), [tpm.md](tpm.md), -[boot-process.md](boot-process.md), [ux-patterns.md](ux-patterns.md). +[boot-process.md](boot-process.md), [ux-patterns.md](ux-patterns.md), +[Heads threat model](https://osresearch.net/Heads-threat-model/) for the user-facing per-board protection status. --- diff --git a/initrd/.bash_history b/initrd/.bash_history index 7ece3035c..d2763e152 100644 --- a/initrd/.bash_history +++ b/initrd/.bash_history @@ -22,3 +22,7 @@ cbmem --console | less # Reboot/power off (important for devices with no keyboard to escape recovery shell) reboot.sh # Press Enter with this command to reboot.sh poweroff.sh # Press Enter with this command to power off +# 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 diff --git a/modules/tpm-gpio-reset b/modules/tpm-gpio-reset new file mode 100644 index 000000000..8d586051c --- /dev/null +++ b/modules/tpm-gpio-reset @@ -0,0 +1,22 @@ +# TPM GPIO Reset Vulnerability PoC (CVE-2025-32399 and related) +# Minimal fork of kukrimate/tpm-gpio-fail: platform families + Makefile fixes only +# Two binaries as in upstream kukri: +# tpm-gpio-detect detection-only audit of GPIO lock status (no CLI args) +# tpm-gpio-assert assertion/execute tool (kukri's modified coreboot inteltool) +modules-$(CONFIG_TPM2_TOOLS) += tpm-gpio-reset + +tpm-gpio-reset_depends := pciutils $(tpm2-tools_dep) +tpm-gpio-reset_repo := https://github.com/tlaurion/tpm-gpio-fail.git +tpm-gpio-reset_commit_hash := 8a9fc3a3c444d04674ef576a9d230d3881c86993 +tpm-gpio-reset_version := $(tpm-gpio-reset_commit_hash) +tpm-gpio-reset_base_dir := tpm-gpio-fail-$(tpm-gpio-reset_version) +tpm-gpio-reset_dir := tpm-gpio-fail-$(tpm-gpio-reset_version) + +tpm-gpio-reset_target := \ + CC="$(heads_cc)" \ + AR="$(AR)" \ + CFLAGS="-Os -I$(INSTALL)/include" \ + LDFLAGS="-L$(INSTALL)/lib" + +tpm-gpio-reset_output := detect/tpm-gpio-detect reset/tpm-gpio-assert +tpm-gpio-reset_install := bin/tpm-gpio-detect bin/tpm-gpio-assert