Message-ID: <aJ8iNLwlf4PAC0h1@kernel.org>
Date: Fri, 15 Aug 2025 15:04:04 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Chris Fenner <cfenn@...gle.com>
Cc: Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
	linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tpm: Disable TCG_TPM2_HMAC by default

On Thu, Aug 14, 2025 at 09:22:52AM -0700, Chris Fenner wrote:
> 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.

All we care here is actually the external verifier scenario because most
of this type of crypto where software must attest breaks without that,
including all confidential computing technologies.

It's true that in the current form the whole feature is at most defense
in depth. It could be e.g. extended with persistent keys and productized
more in the future (e.g., trusted keys were mostly useless for multiple
years).

I'd personally would like to keep it on at least on my own laptop and
there's a risk that there's a group of people who would either:

1. want to have that small amount defense in depth.
2. want to refine the feature.

It's by practical means already "relaxed" but outcomes are objectively
plain wrong (as you stated) so I'd take a bit more conservative approach
on changing the mainline and propose three state option:

1. off: fully turn off
2. relaxed: mark just a info or at most marning to klog that hmac
   encryption is not enable. Keep timeout short as ECC generation
   does not take long (if it is working) (at least according to
   my tests). It should also address the lack of TPM2_ContextSave.
   We really should probe that anyhow in the driver init and
   disable also /dev/tpmrm0 accordingly.
3. strict: enforce. This is good to have albeit now not really
   useful

The 'relaxed' is of course default.

BR, Jarkko

 

Powered by blists - more mailing lists