lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250814162252.3504279-1-cfenn@google.com>
Date: Thu, 14 Aug 2025 09:22:52 -0700
From: Chris Fenner <cfenn@...gle.com>
To: Peter Huewe <peterhuewe@....de>, Jarkko Sakkinen <jarkko@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>
Cc: linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Chris Fenner <cfenn@...gle.com>
Subject: [PATCH] tpm: Disable TCG_TPM2_HMAC by default

This change disables the TCG_TPM2_HMAC feature by default to resolve
some driver initialization failures (with certain TPMs) and performance
regressions (with all TPMs). See "Security remarks" below for why this
does not meaningfully downgrade security.

When the TCG_TPM2_HMAC feature fails to initialize the "null key" (see
tpm-security.rst), it will cause tpm_tis_core_init to bail out early and
skip device registration, causing all userspace requests to /dev/tpm0 to
return ENODEV ("No such device").

TCG_TPM2_HMAC depends on the following being implemented in the TPM:

- TPM_RH_NULL
- TPM2_CreatePrimary
- TPM2_ContextSave
- ECDH-P256
- AES-128-CFB

While the majority of TPMs in the ecosystem conform to the PC Client
Platform TPM Profile, which currently mandates most of these, not all
versions of that profile did, and not all other TPM profiles (e.g.,
Mobile, Automotive, Server) will. The TPM 2.0 specification itself is a
"Library" specification and does not mandate any particular commands
(and very few features) in order to maximize flexibility for
implementors.

The TPM driver should not break userspace for a TPM that conforms to an
atypical profile, therefore this change makes TCG_TPM2_HMAC disabled by
default. It also adds a remark about what will happen if this feature is
enabled and used with a non-supporting TPM to the Kconfig.

Some real-world public examples of problems posed by this feature:

TPMs that do not support the feature result in broken userspace starting
from 6.10:

https://wiki.archlinux.org/title/Trusted_Platform_Module\

Significant (around 200%) boot up latency due to all the added TPM
private key operations:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2080322

Security remarks:

tpm-security.rst describes the threat model of the TPM2_HMAC feature,
wherein an active interposer adversary on the TPM (e.g., SPI) bus
tampers with TPM commands and/or responses to interfere with the booting
or running system. The TPM2_HMAC feature uses something called "salted
sessions" to establish per-request keys that can be used to protect TPM
traffic.

Because the kernel does not have a priori knowledge of a cryptographic
identity for the correct TPM for the system, and because the kernel does
not have any cryptographic identity of its own with which to
authenticate itself to the TPM, the session is established using a
one-sided, unauthenticated key establishment protocol, wherein the
kernel asks the TPM for the so-called "null key" and uses it to
establish the shared session secret.

This poses a serious problem for the threat model of the TCG_TPM2_HMAC
feature, which it resolves by asserting that userspace will attest to
the "null key" using the EK after boot and compare it to the contents of
/sys/class/tpm/tpm0/null_name, exposed by the TPM driver. However, this
creates a trust cycle: we do not trust userspace to perform this action
correctly, because we do not trust that kernel correctly measured
userspace, because nobody has checked the null key yet. An implicitly
trusted remote attestation verifier also cannot be relied upon to do
this check, because it has no way of knowing for certain which key the
kernel actually used to establish the TPM sessions during the boot.

This should probably be discussed in tpm-security.rst in the future.

Signed-off-by: Chris Fenner <cfenn@...gle.com>
---
 drivers/char/tpm/Kconfig | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index dddd702b2454..ad419ca97b8d 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -29,7 +29,7 @@ if TCG_TPM
 
 config TCG_TPM2_HMAC
 	bool "Use HMAC and encrypted transactions on the TPM bus"
-	default X86_64
+	default n
 	select CRYPTO_ECDH
 	select CRYPTO_LIB_AESCFB
 	select CRYPTO_LIB_SHA256
@@ -39,7 +39,10 @@ config TCG_TPM2_HMAC
 	  communicating with the TPM to prevent or detect bus snooping
 	  and interposer attacks (see tpm-security.rst).  Saying Y
 	  here adds some encryption overhead to all kernel to TPM
-	  transactions.
+	  transactions.  If the TPM does not implement a command or
+	  algorithm required by the feature, it will not be registered
+	  during initialization, and userspace will fail to open the
+	  TPM with ENODEV.
 
 config HW_RANDOM_TPM
 	bool "TPM HW Random Number Generator support"
-- 
2.51.0.rc0.215.g125493bb4a-goog


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ