tpm_emulator: the qemu process will be blocked while receiving an unexpected ctrl command's response from the swtpm
Host environment
- Operating system:Linux - Fedora 40
- OS/kernel version:6.10.8-200.fc40.x86_64
- Architecture:x86-64
- QEMU flavor:qemu-system-x86_64
- QEMU version:qemu-8.2.6-3.fc40.x86_64
- QEMU command line:
Emulated/Virtualized environment
- Operating system:Windows 11
- Architecture: x86-64
Description of problem
When the swtpm sends the unexpected ctrl command's repsonse to the qemu process, the qemu will be blocked. When we use the gdb to attach the qemu process, we will find out that the qemu process is blocked in recv_msg function.
Steps to reproduce
1.The QEMU process sends a CMD_GET_TPMESTABLISHED control command to the swtpm.
2.If the swtpm is not currently active (tpm_running is false), it responds to the QEMU process with an err_not_running message, which has a fixed size of 4 bytes.
(Reference: https://github.com/stefanberger/swtpm/blob/master/src/swtpm/ctrlchannel.c#L938)
3. However, the QEMU process expects to receive a valid response (ptm_est est) of 8 bytes. Consequently, the QEMU process will be blocked in the recv_msg function if the response does not match the expected format.
Additional information
After analysing the source codes in tpm_emulator.c, we found that qemu does not process the unexpected ctrol command response from the swtpm correctly (e.g. CMD_GET_TPMESTABLISHED). The qemu would be blocked in this function if it received unexpected response from the swtpm (https://gitlab.com/qemu-project/qemu/-/blob/3e9f48bcdabe57f8f90cf19f01bbbf3c86937267/backends/tpm/tpm_emulator.c#L140).