On 12/17/20 10:54 AM, Marc-André Lureau wrote:
Hi On Wed, Dec 16, 2020 at 11:45 PM Michael Weiser ...
Could it be as easy as booting a recovery linux distro and
comparing the
outputs of dmidecode or somesuch?
I am afraid it's not so easy. We should probably consider new tests
to ensure version machines get the same PCR measurement from
bios/uefi. That's what OS usually rely on, but they may probe more
hardware related details themself too.
I created now this wiki page for swtpm:
https://github.com/stefanberger/swtpm/wiki/Sealing-to-PCR-0-7-Values-when-using-QEMU
The whole purpose of measured/trusted boot is to reflect some known
measurement values of a known BIOS in the TPM PCRs. Unfortunately this
bites with sealing to those values and the rather fast development of
QEMU. Updates of QEMU on the host platform then become a recovery event
inside the VM, which is unfortunate, but this is when measured/trusted
boot actually 'does its job'.
For giggles I did enter the recovery key of the testing VM when
prompted. It did boot up and showed Bitlocker enabled. After rebooting
it prompted for the recovery key again. I entered it again, it booted
again and I turned off Bitlocker (decrypted the disk). After
re-enabling
Bitlocker (re-encrypting the disk) and rebooting again it now does not
prompt for the recovery key again.
Does Bitlocker not allow you to accept a configuration change (= PCR
value change) and it internally (presumably) then seals the secreted
against those new values so upon the next reboot it works again? Do you
really need to go through the whole re-encryption process? It sounds
like unattractive even for a physical machine firmware update...
Stefan
