blob: b336da267e0f9c6e83be936e4a4c89f9ccfb5bd1 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
device: 0.903
performance: 0.871
ppc: 0.860
graphic: 0.821
files: 0.730
TCG: 0.679
register: 0.664
network: 0.663
risc-v: 0.620
vnc: 0.618
semantic: 0.565
debug: 0.556
architecture: 0.532
permissions: 0.471
i386: 0.449
socket: 0.435
peripherals: 0.420
mistranslation: 0.406
PID: 0.376
VMM: 0.355
user-level: 0.353
boot: 0.329
arm: 0.322
x86: 0.317
assembly: 0.262
hypervisor: 0.256
virtual: 0.238
kernel: 0.153
KVM: 0.127
tpm_emulator: the qemu process will be blocked while receiving an unexpected ctrl command's response from the swtpm
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).
|