Thanks James, On Tue, Aug 19, 2025 at 1:51 AM James Bottomley <[email protected]> wrote:
> The point being that the kernel TPM2 driver was built to support a > standard spec TPM2 with context management. Which "standard spec"? The PC Client Platform TPM profile? Is the TPM2 driver intended to break userspace for any other TPM? > > 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). Nice, we're on the same page here, then. So let's game out this attack. The interposer attacker has attempted to boot some malicious code undetected, and it used its interposer capability to cause the non-malicious firmware/bootloader/kernel code to mis-measure and transition to the malicious code. > > 2. When is this system (and its durable storage) validated or > > measured? > Usually in the initrd before root is decrypted. I see 2 cases here, either the initrd is malicious or it's not, right? If malicious then it will skip the checks, if not malicious what will it check against or measure into? The interposed TPM, right? > > 3. How do we avoid a circular trust dependency between the kernel and > > this system here? > 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. Indeed I am worried about this exact case, since we said earlier the interposer is trying to boot malicious code undetected. How does the remote system know which key the kernel used for all its salted sessions? Thanks Chris
