On Mon, 2025-08-18 at 09:12 -0700, Chris Fenner wrote: > Thanks James, > > On Sun, Aug 17, 2025 at 1:34 AM James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > Supporting these commands was the reason the TPM2 volatile > > handle space was reduced to 3. > > I think this may put the cart before the horse: You can do anything > you want to in the TPM with just 3 handles (actually I think 2 might > be enough). ContextSave and ContextLoad exist [1] so that you can > create a resource manager to share the TPM among concurrent > applications. If you aren't sharing the TPM among concurrent > applications, you neither need a resource manager nor context > commands. I want to make sure I'm not misunderstanding your message: > is it OK to break userspace over this or any other [2] missing > dependency of TCG_TPM2_HMAC, simply because that implies the TPM is > not a "mainstream" PC Client profile TPM?
Well you are slightly misunderstanding it, yes. Context management commands are mandatory for a TPM2 because of the need for resource management, even in single user situations, because the TPM can get used by multiple applications if you use things like TPM resident keys. The point being that the kernel TPM2 driver was built to support a standard spec TPM2 with context management. We could actually generate the primary on the fly instead of context saving it ever time, but that adds overhead it wouldn't be fair to burden everyone else who has a fully compliant TPM2 with. It may actually be possible to detect the lack of context commands in the init probe and turn off both the in kernel resource manager and do on the fly generation for HMAC for that case without burdening the fast path, so perhaps google might like to look into that? The chip->cc_attrs_table should have the full list of supported commands (after probe). > > The way it is supposed to work is that the system stores (and > > validates if it can) the signing EK on install (this is constant > > for the lifetime of the TPM). > > Some questions for the threat model here: > 1. Where is the signing EK stored by the system? On durable storage. The threat model being that an interposer attacker is seeking to gain access to keys or boot malicious code undetected (so detection, even after the fact, is good enough). > 2. When is this system (and its durable storage) validated or > measured? Usually in the initrd before root is decrypted. > 3. How do we avoid a circular trust dependency between the kernel and > this system here? The null primary certification is done in userspace so its independent of kernel or TPM crypto. If you're worried the attacker has compromised the system far enough to corrupt a user space crypto operation then you can ship the verification off to a remote system. Regards, James
