My conclusion about TCG_TPM2_HMAC after [1] and [2] was that TPM2_TCG_HMAC doesn't (or didn't at the time) actually solve the threat model it claims to (active interposer adversaries), while dramatically increasing the cost of many kernel TPM activities beyond the amount that would have been required to just solve for passive/bus-sniffer interposer adversaries. The added symmetric crypto required to secure a TPM transaction is almost not noticeable; the big performance problem is the re-bootstrapping of the session with ECDH for every command.
My primary concern at that time was, essentially, that TCG_TPM2_HMAC punts on checking that the key that was used to secure the session was actually resident in a real TPM and not just an interposer adversary. I wrote up my understanding at https://www.dlp.rip/decorative-cryptography, for anyone who wants a long-form opinionated take :). Unless I'm wrong, or TCG_TPM2_HMAC has changed dramatically since August, I don't think "TPM2_TCG_HMAC makes this too costly" is a compelling reason to make a security decision. (There could be other reasons to make choices about whether to use the TPM as a source of randomness in the kernel! This just isn't one IMHO.) The version of TCG_TPM2_HMAC that I'd like to see someday would be one that fully admits that its threat model is only passive interposers, and sets up one session upon startup and ContextSaves/ContextLoads it back into the TPM as needed in order to secure parameter encryption for e.g., GetRandom() and Unseal() calls. [1]: https://lore.kernel.org/linux-integrity/CAMigqh2nwuRRxaLyOJ+QaTJ+XGmkQj=rmj5k9gp1bccxp2o...@mail.gmail.com/ [2]: https://lore.kernel.org/linux-integrity/[email protected]/ Thanks Chris On Fri, Feb 20, 2026 at 10:04 AM Mimi Zohar <[email protected]> wrote: > > [Cc: Chris Fenner, Jonathan McDowell, Roberto] > > On Sun, 2026-01-25 at 21:25 +0200, Jarkko Sakkinen wrote: > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its > > use should be pooled rather than directly used. This both reduces > > latency and improves its predictability. > > If the concern is the latency of encrypting the bus session, please remember > that: > > - Not all environments expose the TPM bus to sniffing. > - The current TPM trusted keys design is based on TPM RNG, but already allows > it > to be replaced with the kernel RNG via the "trusted_rng=kernel" boot command > line option. > - The proposed patch removes that possibility for no reason. > > Mimi & Elaine > >
