Different PCR digests for "host" and "qemu" configuration

[Anatol Pomozov]

Hi

I am writing a test for systemd-cryptenroll. I have a Linux host, run swtpm as 

swtpm socket --tpmstate dir=assets/tpm2 --tpm2 --server type=tcp,port=2321 --ctrl type=tcp,port=2322 --flags not-need-init,startup-clear &

Then enrolling to it using 'systemd-cryptenroll --tpm2-device=swtpm:' and it works fine.

After that I run a unit test written in Go which tries to compute PCR digest for the metadata of this newly encrypted slot. The most interesting part of the test is here https://gist.github.com/anatol/0483bd1b519e13d0ce9112e72f0f7055

The unit test works fine!

Now I am running exactly the same test inside QEMU. To make it happen I run qemu with `-chardev socket,id=chrtpm,path=assets/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0` parameters. The unit test opens /dev/tmprm0 and tries to run exactly the same commands sequence as at the host machine.

Unfortunately exactly the same golang code fails because TPM returns different PRC digest.

I am trying to understand what is going on here. Are there condition when PCR digest can be different between host and QEMU for exactly the same swtpm instance? And if yes how to prevent it? I need to make sure that my QEMU tests see exactly the same TPM state as was seen by 'systemd-cryptenroll' at the host machine.

My machine configuration:

QEMU 6.1.0

swtpm 0.6.0

systemd 249.4

up-to-date Arch Linux

[Stefan Berger]

Can you try with the latest libtpms version from github. Maybe it's related to a bug I recently fixed.

My machine configuration:

QEMU 6.1.0

swtpm 0.6.0

systemd 249.4

up-to-date Arch Linux

--
You received this message because you are subscribed to the Google Groups "swtpm-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swtpm-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/swtpm-user/3714d600-b33e-4017-b505-8e331565f67bn%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anatol Pomozov]

Hello

On Sat, Sep 11, 2021 at 5:38 PM Stefan Berger <ste...@linux.ibm.com> wrote:

On 9/10/21 9:34 PM, Anatol Pomozov wrote:

Hi

I am writing a test for systemd-cryptenroll. I have a Linux host, run swtpm as 

swtpm socket --tpmstate dir=assets/tpm2 --tpm2 --server type=tcp,port=2321 --ctrl type=tcp,port=2322 --flags not-need-init,startup-clear &

Then enrolling to it using 'systemd-cryptenroll --tpm2-device=swtpm:' and it works fine.

After that I run a unit test written in Go which tries to compute PCR digest for the metadata of this newly encrypted slot. The most interesting part of the test is here https://gist.github.com/anatol/0483bd1b519e13d0ce9112e72f0f7055

The unit test works fine!

Now I am running exactly the same test inside QEMU. To make it happen I run qemu with `-chardev socket,id=chrtpm,path=assets/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0` parameters. The unit test opens /dev/tmprm0 and tries to run exactly the same commands sequence as at the host machine.

Unfortunately exactly the same golang code fails because TPM returns different PRC digest.

I am trying to understand what is going on here. Are there condition when PCR digest can be different between host and QEMU for exactly the same swtpm instance? And if yes how to prevent it? I need to make sure that my QEMU tests see exactly the same TPM state as was seen by 'systemd-cryptenroll' at the host machine.

Can you try with the latest libtpms version from github. Maybe it's related to a bug I recently fixed.

I updated my host's libtpms to 0.8.6 and it did not solve the problem.

I ran the policyPCRSession() from the code above at 2 different machines and direct swtpm returns the same hash for PCR [7]. The hash value is 8b5682d81b29435d08d79278150611dc7e5923b2fefcce684a09577b40130a8b

But the swtpm->qemu environment returns a5912c738a0c9cdaa91f199f73805fab267cea85352b15ab382f482063598421 digest for exactly the same PCR set.

[Anatol Pomozov]

Here is a simple golang program that prints digest for a PCR set (by default it is [7])

https://gist.github.com/anatol/1f8614e24a708d5bc33d260a04be68f5

First run swtpm as specified in the problem and then run the program itself `go run ./main.go`.

[Stefan Berger]

On 9/11/21 9:17 PM, Anatol Pomozov wrote:

Here is a simple golang program that prints digest for a PCR set (by default it is [7])

https://gist.github.com/anatol/1f8614e24a708d5bc33d260a04be68f5

First run swtpm as specified in the problem and then run the program itself `go run ./main.go`.

If you have a firmware running that extends PCRs then  it's not a surprise that you will get a different result inside the VM because PCrs 0-7 may already have values then.

   Stefan

 

[Anatol Pomozov]

Hi Stefan

Thanks for the hint. I tried to bind to other PCRs (10 and 12) and now my test passes.

The QEMU firmware is edk2. What is the reason it does this PCR extension.

[Stefan Berger]

The firmware measures parts of itself and other components into various PCRs: https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v21.pdf

Search for strings like pcr[1]  .