On Sun, Mar 06, 2022 at 04:47:58PM +, Etienne Dechamps wrote:
> 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.
Thanks for the bug report. Apparently upstream renamed the flag to
enable the TPM, so we need to adjust the build:
https://github.com/tianocore/edk2/commit/4de8d61bcec02a13ceed84f92b0cf3ea58adf9c5
-dann
