Hi all, I'm investigating an issue where the TPM driver breaks on the latest upstream kernel. I believe I've tracked it down to the HMAC session feature that primarily lives in drivers/char/tpm/tpm2-sessions.c.
Our TPM doesn't support TPM2_ContextSave. So we get the following call stack during initialization: 1. tpm_tis_init calls 2. tpm_tis_core_init, which calls 3. tpm_chip_bootstrap, which calls 4. tpm_auto_startup, which calls 5. tpm2_auto_startup, which calls 6. tpm2_sessions_init, which calls 7. tpm2_create_null_primary, which calls 8. tpm2_save_context, which fails because the command is not supported. This causes tpm_tis_core_init to skip the call to tpm_chip_register. This causes processes trying to open /dev/tpm0 to hit the error "no such device" I have two main concerns about this feature: 1. It seems problematic that the kernel autonomously sends not-strictly-necessary traffic to the TPM, and breaks userspace if it fails. I would define "strictly necessary" traffic as things like calling TPM2_Startup. 2. It's not clear to me that the HMAC session feature solves its own threat model. Reading through the documentation at the top of https://github.com/torvalds/linux/blob/master/drivers/char/tpm/tpm2-sessions.c, it seems like we assume that the adversary either isn't sophisticated enough to interpose the CreatePrimary command, or that userspace somehow recovers trust after the fact by attesting the null key with the EK. I'm not sure how this is expected to work, given this userspace wasn't correctly measured into the TPM (due to the interposer) and could therefore be malicious. Is someone able to help me fill in the gaps in my understanding here? Thanks Chris
