Hello,
I have a Windows 10 with BitLocker activated running happily in
libvirtd/virt-manager.
After upgrading to qemu 5.2.0 it refuses to boot and presents a screen
with blue background where Bitlocker explains that the hardware
configuration has changed and I need to enter a recovery key.
Going back to 5.1.0 makes it boot again.
Is this expected behaviour?
How can I figure out what trips Bitlocker?
I was expecting to work around this kind of issue by using a VM and
keeping the virtualised hardware stable (e.g. -machine pc-q35-5.1).
IIRC I needed to activate swtpm in TIS and version 1.2 mode by trial and
error because that was the only combo that worked for Bitlocker. The
Afaik, TPM 2.0 + CRB should be working. Which exact version of Windows is it? Did you make any upgrade?
machine runs in BIOS mode and thus without SecureBoot because I wanted
internal snapshots to work.
I have extracted and simplified the qemu command from libvirtd somewhat
and can reproduce the issue while running swtpm manually.
I have verified the behaviour with a freshly installed Windows 10 and
qemu 5.2.0 and today's git HEAD compiled from source.
The following exact same commands have the machine booting when using
qemu 5.1.0 and end up in the Bitlocker recovery screen when using 5.2.0
or git HEAD:
/usr/bin/swtpm socket
--ctrl type=unixio,path=11-win10-bitlocker-swtpm.sock,mode=0600
--tpmstate dir=bf566263-35e3-4dba-af8c-8ca85dba6a85/tpm1.2,mode=0600
qemu-system-x86_64 -machine pc-q35-5.1 -m 4096
-uuid bf566263-35e3-4dba-af8c-8ca85dba6a85 -no-user-config
-blockdev '{"driver":"file","filename":"win10-bitlocker.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}'
-device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1
-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm
-chardev socket,id=chrtpm,path=11-win10-bitlocker-swtpm.sock
-device tpm-tis,tpmdev=tpm-tpm0,id=tpm0
You have made great work in reporting the issue, would you be kind enough to do a git bisect ? That would be of great help!
(not much happened in hw/tpm tree between 5.1 and 5.2 that can easily explain this regression)
Stefan Berger is the TPM maintainer, added in CC.