Package: ovmf Version: 2022.02-1 Severity: important Control: fixed -1 2021.11-1
An ovmf regression somewhere between 2021.11-1 and 2022.02-1 makes it impossible to use a TPM in Windows guest VMs (tested with various Windows 11 builds). The Windows Device Manager shows the TPM as defective, with the error "This device cannot start. (Code 10) A protocol error was detected between the driver and the device". tpm.msc shows no TPM is available. One consequence is that Windows 11 refuses to install with ovmf 2022.02-1, since the Windows 11 installer demands a functional TPM. Steps to reproduce using qemu-system-x86 1:6.2+dfsg-2 and swtpm 0.7.1-1: # mkdir /tmp/tpm # swtpm socket --tpm2 --tpmstate dir=/tmp/tpm --ctrl type=unixio,path=/tmp/tpm/sock & # qemu-system-x86_64 -enable-kvm -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd -chardev socket,id=tpm,path=/tmp/tpm/sock -tpmdev emulator,id=tpm,chardev=tpm -device tpm-tis,tpmdev=tpm … With ovmf 2021.11-1, the TPM is functional in Windows using the above parameters; with 2022.02-1, it is not. Switching to "tpm-crb" doesn't seem to make any difference. In Linux guests the TPM appears to be functional, although the guest kernel outputs the following messages with 2022.02-1: tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1) tpm tpm0: A TPM error (256) occurred attempting the self test tpm tpm0: starting up the TPM manually With 2021.11-1, the kernel only outputs the first line - no errors.
