trustee-attester failing on TPM access in TDX VM since 0.16.0

[berrange]

Describe the bug

Since updating to 0.16.0, attempts to run trustee-attester in my TDX development VM fail with an error about incorrect TPM handle usage

  "the handle is not correct for the use (associated with handle number 1)"

Bisecting points to the changes in #1093 to introduce the TPM as a secondary attestation device.

This is a TDX virtual machine running under KVM with QEMU 10.1.2. The VM is configured with a virtual TPM backed by swtpm 0.10.1 on the host OS. Such a host backed vTPM should NOT be trusted to be confidential, and thus arguably is pointless to enable it in a VM. None the less trustee formerly worked and now it fails.

The first question is what is the root cause of trustee having incorrect TPM handle usage "Error when getting ESYS handle from TPM handle: the handle is not correct for the use (associated with handle number 1)" and how can that be fixed ?

Second, if collecting evidence from the primary TEE succeeds, a failure to collect evidence from a secondary device perhaps should not be a fatal error.

The trustee server configured attestation policy ought to be enforcing whether the absence of attestation info from the secondary device is considered fatal or not.

How to reproduce

Create a QEMU/KVM TDX enabled VM, with an swtpm backed virtual TPM present. I suspect the same may happen with a QEMU SEV-SNP VM too, if swtpm is present, but I have not personally tested that.

Attempt to attest it with trustee-attester version 0.16.0 or later

CoCo version information

guest-components 0.16.0

What TEE are you seeing the problem on

Tdx

Failing command and relevant log output

# ./trustee-attester  --url http://192.168.122.1:9000   get-resource --path fo/bar/wiz
[2026-01-23T13:28:46Z INFO  attester::tpm::utils] TPM device detected: /dev/tpm0
[2026-01-23T13:28:46Z INFO  attester::tpm::utils] AA_TPM_AK_HANDLE not set, using default handle: 0x81010002
[2026-01-23T13:28:46Z INFO  attester::tpm] [TPM Attester] Initialized using TPM device: /dev/tpm0 and AK handle: 2164326402
[2026-01-23T13:28:46Z INFO  attester::tpm::utils] TPM device detected: /dev/tpm0
[2026-01-23T13:28:46Z INFO  attester::tpm::utils] AA_TPM_AK_HANDLE not set, using default handle: 0x81010002
[2026-01-23T13:28:46Z INFO  attester::tpm] [TPM Attester] Initialized using TPM device: /dev/tpm0 and AK handle: 2164326402
[2026-01-23T13:28:46Z INFO  attester::tpm::utils] Creating TCTI configuration for device: /dev/tpm0
WARNING:esys:src/tss2-esys/api/Esys_ReadPublic.c:320:Esys_ReadPublic_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/esys_tr.c:278:Esys_TR_FromTPMPublic_Finish() Error ReadPublic ErrorCode (0x0000018b) 
ERROR:esys:src/tss2-esys/esys_tr.c:402:Esys_TR_FromTPMPublic() Error TR FromTPMPublic ErrorCode (0x0000018b) 
[2026-01-23T13:28:46Z ERROR tss_esapi::context::general_esys_tr] Error when getting ESYS handle from TPM handle: the handle is not correct for the use (associated with handle number 1)
[2026-01-23T13:28:46Z INFO  tss_esapi::context] Closing context.
[2026-01-23T13:28:46Z INFO  tss_esapi::context] Context closed.
[2026-01-23T13:28:46Z WARN  kbs_protocol::client::rcar_client] RCAR handshake failed: RcarHandshake("Error {\n    context: \"get composite evidence failed\",\n    source: GetEvidence(\n        \"the handle is not correct for the use (associated with handle number 1)\",\n    ),\n}"), retry 1...

[fitzthum]

The quick fix is to build the Trustee attester without the TPM attester. You can do something like --no-default-features --features tdx-attester or add any other attesters that you do need.

[fitzthum]

The basic idea with the PR you are pointing to is to treat the TPM as an additional device alongside a primary platform attestation (such as a CPU). Practically speaking this means that previously if a CPU platform was found, the TPM attestation would likely be skipped (I forget the exact order of discovery tho). Now, both attesters will be run. This is what we want. Later in the attestation flow your non-confidential TPM will in theory be revealed for what it is. It looks like there is some bug in the attester an it is not able to handle the TPM. The TPM code is relatively new. cc @bpradipt

As a side note, eventually we will introduce another attester that can handle confidential vTPMs. Basically we would create an additional attester for the SVSM, allowing us to treat the TPM, SVSM, and CPU mostly separately and generically.

[fitzthum]

I suspect that maybe the issue comes when the attester tries to read the AK public key from the TPM. It could be that the TPM has a different key hierarchy than what we expect, or it's possible that the TPM just hasn't been setup correctly. Currently the TPM attester expects the TPM to have the hierarchy used for quote endorsement setup ahead of time (and known by the verifier). This model is more suited to physical TPMs perhaps. We don't yet have an automated flow for setting up these keys.

To debug, I would look around here and see if that is indeed where things go wrong and what exactly the attester expects.

[berrange]

I suspect that maybe the issue comes when the attester tries to read the AK public key from the TPM. It could be that the TPM has a different key hierarchy than what we expect, or it's possible that the TPM just hasn't been setup correctly.

AFAIK in the swtpm setup there is no AK present at all. There is an EK cert, and platform cert. There is no AK with handle 0x81010002.

If trustee expects an AK, then either it has to create one, or it must gracefully skip a TPM without an AK.

[fitzthum]

The reasoning behind the general flow was discussed on the original PR. See this comment. In the future we will couple the AK to the hw evidence automatically. This will take the place of the a priori AK setup that is expected now.

We could make the AK pub an optional field in the TPM evidence struct, but I'm not sure how much that gets us. The verifier expects the AK pub to be there and will try to compare it against a list of allowed AK pubs. So we really do expect the guest to have put an AK into the TPM and tell the verifier about it "ahead of time." This is more suited for physical TPMs at the moment, but like I said we are hoping to improve.

[berrange]

I wasn't suggesting to make the AK field optional per-se. Rather that if there is an error interacting with the TPM, discard the TPM evidence,and only submit the TDX/SNP/etc evidence - ie treat a broken TPM the same as if /dev/tpm0 did not exist at all.

From a trustee server POV it cannot rely on there being any distinction between "trustee-attester built without TPM device", "trustee-attester built with TPM, but /dev/tpm0 does not exist", and "trustee-attester built with TPM device, but TPM device is broken". trustee-attester is untrusted guest software, so those three scenarios are all expected from the attestation server POV. The server policy has to define what to do when any single piece of evidence is absent (whether thats the TPM quote or TDX or SNP quote).

[fitzthum]

trustee-attester is untrusted guest software

Well the trustee-attester generally should be part of the guest measurement. It is trusted to do things like generating composite evidence from individual evidence and detecting which devices are present (although there are some details here about how exactly the devices get enabled). There is a difference between skipping a TPM that isn't setup as expected and building the attester with no TPM support. I think we probably don't want to do the first thing, but I need to think about it a bit more.

[mkulke]

I suppose it's rather a question of robustness than trusted/untrusted? all attesters are untrusted until they passed remote attestation.

For software in the TCB ambiguity is not great, so I'd sympathise with the attester bailing out once it encounters something unexpected.

But maybe the expectations here are too intrusive: the mere presence of a TPM (or a cc-capable GPU) might not indicate that they have to be part of the evidence.

Detecting the presence of the AK w/ a well-known handle is just a heuristic like the detection of e.g. /dev/sev-guest. Maybe that model doesn't scale very well, especially with composite evidence. I could imagine that the AS has a runtime config/cli toggle to pick the attester devices the user intends to use. Maybe it should even be mandatory, so that you'd have to opt-in explicitly. people wouldn't be accidentally using the sample attester as a bonus.

[fitzthum]

I generally agree with @mkulke, but here is the tricky case. Let's say I expect to have an SNP guest with a GPU attached to it. I write a policy that releases secrets only to that kind of guest. What happens if another device is added to the guest but not reported by the AA? In fact a vTPM emulated on the host can leak a ton of information about the guest. If one is present, perhaps especially if it isn't in the expected configuration, shouldn't the relying party know about this (or some other blocking error)?

I guess we could treat this as something in the realm of the agent policy, but I'm not sure how robust our device support is there, and ofc here we are talking about a VM without CoCo. Ofc the AA won't know about every possible device that could be attached to a guest. I have wondered about including some platform info in the runtime data. This could include the output of lscpi or something so that the rp always has a clear view of that guest configuration. We would have to trust the AA to provide that correctly.

[berrange]

Well the trustee-attester generally should be part of the guest measurement. It is trusted to do things like generating composite evidence from individual evidence and detecting which devices are present

I can't quite come up with convincing problem scenarios but the idea of relying on the integrity of the attestation agent as part of the attestation process makes me somewhat wary.

The mental model I had was that the attestation agent could be untrusted, with the only reliance being on the hardware providing the attestation report(s).

I can see though, that if trustee-attester is part of the initrd, and the initrd is inside a measured unified kernel image, that would in turn fairly easily establish integrity for trustee-attester when it is running during initrd phase.

Later use of trustee-attester feels possibly less robust. If trustee-attester is run from the root filesystem during normal OS operation, it is possible that the root FS has not been covered directly by any measurement. In a traditional VM world, it may merely be protected by disk encryption. There's also weaker guarantees that what's executing in memory actually matches what's on disk, since /proc/$PID/mem or ptrace() can poke data.

The latter would rather imply your OS has been compromised though, at which point even if you can securely attest that you're running in a CVM, that doesn't really save you.

What happens if another device is added to the guest but not reported by the AA? In fact a vTPM emulated on the host can leak a ton of information about the guest. If one is present, perhaps especially if it isn't in the expected configuration, shouldn't the relying party know about this (or some other blocking error)?

Wanting to proving the absence of some piece of hardware is challenging. I think that takes you down the road of having to attest the full enumeration of the virtual hardware that's present, or you have to build a constrained kernel + config that will refuse to use any hardware except for a small "allow list", contrary to Linux's normal behaviour of auto-loading drivers for everything that is detected.

[fitzthum]

The mental model I had was that the attestation agent could be untrusted, with the only reliance being on the hardware providing the attestation report(s).

There is some risk to having attestation interfaces exposed to potentially undefined guest behavior. In CoCo we at least have container isolation between the workload and the guest components (although this is not foolproof). In CVMs there is a less of a boundary. In a secure workload this shouldn't be an issue, but I would not be against running the attesters in VMPL0 at some point if feasible.

Either way, a guest can't undermine the hw evidence, but there are still some risks. Mainly, the multi-device code depends on the AA implementing composite evidence correctly. An untrusted AA could omit certain devices or pull valid device evidence from another guest and insert it into the KBS protocol. Binding the evidence together prevents this from happening once the evidence leaves the guest, but we rely on the guest components to do this binding.

Wanting to proving the absence of some piece of hardware is challenging. I think that takes you down the road of having to attest the full enumeration of the virtual hardware that's present, or you have to build a constrained kernel + config that will refuse to use any hardware except for a small "allow list", contrary to Linux's normal behaviour of auto-loading drivers for everything that is detected.

Totally agree. You should already be able to make a secure workload with a bit of hardening, whether it is in the kernel or the kata agent policy. Either way ofc we are trusting the guest to follow the rules and it's possible that the configuration could be modified over time and a device could be hotplugged.

So there is certainly some subtlety here, and maybe some things to improve, but I still feel that it is generally safer not to have the attester fail silently.