Re-establishing connection if swtpm process restarts

[daghaian]

Hi @jx6f ,

I stumbled across your project which I found a use for (not for tamper purposes), but to proxy a unix file from QEMU to swtpm and vice-versa. I'm trying to find where I could modify your existing logic, to account for the scenario where the TCP connection to the swtpm server/control, dies for any reason. I"m not have any a ton of luck but ideally I want to contribute a retry logic to re-establish the connection. From what I can tell right now, the logic in exchange.go hangs here:

tpmproxy/exchange.go

Line 38 in cf78194

responseLen, err := ex.Dst.Read(respBuf)

As expected, my guest throws the following:

ERROR:tcti:src/tss2-tcti/tcti-device.c:487:Tss2_Tcti_Device_Init() timeout waiting for response from fd 3
ERROR:sys:src/tss2-sys/api/Tss2_Sys_Execute.c:110:Tss2_Sys_ExecuteFinish() Unsupported device. The device is a TPM 1.2
ERROR: GetCapability:Get NV Index list Error. TPM Error:0x80001
ERROR: Unable to run /usr/bin/tpm2_nvlist

Any insight would be appreciated!

[daghaian]

Ended up confirming that adding a re-dial of the network connection (srv or control TCP destination), works. If you have any suggestions I'd love to hear them. Otherwise, I'll propose a modification to include retry logic.

[daghaian]

Interestingly enough, I know this library was created with the intention of being used for learning/tampering (and not for production), but my application is to use this to proxy (within a K8s cluster), traffic between 2 pods (one running the SWTPM, and one running the QEMU VM). This allowed me pre-program a TPM device externally from the guest, and then have the QEMU VM proxy its TPM traffic to the other pod in the cluster.

We are hoping to utilize this approach for our VM as a service production offering. Thanks for the library!

[jx6f]

Hi @daghaian ,

Thank you for your proposal.
I wanted to clarify if you are envisioning a scenario where only SWTPM is restarted while QEMU is running.
If that's the case, there's a possibility that the states of the guest OS and SWTPM could become inconsistent, including PCR values and context.
While applying this to a production environment might present some challenges, I appreciate the suggestion given that tpmproxy is an experimental library.

Thank you.

[daghaian]

Yes, the intent is to continue to manage the swtpm process external to the pod running QEMU. I do not believe our use case is overly concerned about use of PCR, more-so basic encryption/decryption and reading from NV.

On the PCR topic though, is this not preserved in swTPMs persistent state?

Any other concerns around this usage pattern I should be aware of?

[jx6f]

Yes, PCR values are not persistent and should be reset upon the restart of SWTPM. TPM-JS will be a useful reference: https://google.github.io/tpm-js/#pg_pcrs

Furthermore, I believe that inconsistencies could potentially arise with the TPM context and sessions. Given that the TPM is not designed as a pluggable device, developing systems that involve restarting the TPM could present significant challenges. It might be beneficial to consult with the community at TPM.dev for valuable advice: https://developers.tpm.dev/

[daghaian]

"Furthermore, I believe that inconsistencies could potentially arise with the TPM context and sessions. "

If we launch swtpm with --no-needinit,--startup-clear

Wont that reset state each ttime safely?

[jx6f]

While SWTPM itself will be reset, the guest OS within QEMU could potentially retain context and session states.

It's conceivable that if the SWTPM is restarted at an opportune moment, no issues might arise. However, if the timing is unfavorable, the precise nature of the problems that could occur is difficult to predict accurately.

[daghaian]

What would be the ideal scenario I wonder though? If you're dealing with QEMU in general, even if QEMU + libvirt, libvirt launches a swtpm process, it can go unhealthy and crash, no? I dont believe QEMU restarts just cause the swtpm process goes unhealthy, but I could be wrong.

[jx6f]

I'm not entirely clear on your meaning. Are you suggesting something along the lines of the inherent impossibility of creating software that is entirely free of bugs?

[daghaian]

No no, of course not haha. Im just trying to understand if you're suggesting that the proposed approach I've defined is any diifferent than inherent risks that come along with libvirt + qemu and a swtpm

[jx6f]

Understood. I'll explain it later as far as I understand it, but I might be wrong. If you need more accurate information, I recommend TPM.dev.

[jx6f]

By the way, how can I reproduce the problem you reported? I am trying to reproduce the problem with the following steps now, but I don't get any problematic behavior.

1. run swtpm: swtpm socket --tpmstate dir=/path/to/swtpm/state/dir --tpm2 --server port=2321 --ctrl type=tcp,port=2322
2. run qemu_swtpm_forward: go run github.com/CyberDefenseInstitute/tpmproxy/example/qemu_swtpm_forward@latest
3. run qemu: qemu-system-x86_64 (qemu options other than TPM) -chardev socket,id=chrtpm,path=/tmp/qemu_swtpm_fwd.sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
4. kill swtpm(Ctrl+C)
5. run swtpm again

When I run it with these steps, qemu_swtpm_forward finished normally without outputting any errors. This is the behavior I expect.
Please tell me the steps to reproduce your problem. I don't have enough knowledge of libvirt and I don't know what process libvirt controls swtpm through. Please tell me the steps using swtpm and qemu commands without using libvirt.