qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Choosing PCR banks for swtpm's TPM 2


From: Stefan Berger
Subject: [Qemu-devel] Choosing PCR banks for swtpm's TPM 2
Date: Mon, 25 Jun 2018 11:05:55 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Hi!

 I am sending this email to solicit input on the choice of the PCR banks to enable for swtpm's TPM 2. I have currently enabled 4 PCR banks for SHA{1,256,384,512}. The downside of this is that running the TPM 2 with so many PCR banks has a performance impact when the Linux integrity measurement architecture is used and has to extend measurements into all PCR banks, which Linux does already.

TPM 2 has the PCR_Allocate() command for a user to select the PCR banks to use. This command allows to make some PCR banks invisible. The change has to be done through the firmware and has the downside that the TPM2 does not support TPM2_Shutdown(SU_STATE) after this command was used. This prevents suspend/resume from working properly. So, it seems that one shouldn't have to use this command, which in turn means the number of PCR banks should be small.

Another complication with the swtpm is the upgrade path. Suspended VMs will expect that the PCR banks that were available before the suspend will be available after the resume and a possible swtpm upgrade. This in turn means that the PCR banks should be chosen now and we'll have to stick with them.

That said, my suggestion would be to enable only PCR banks for SHA256 for 'now' and SHA512 for the future. Having two PCR banks should enable decent performance. If someone wants to have better performance he will have to go through the firmware to select the PCR banks at the expense of loosing suspend/resume support.

The change of PCR banks for the current 4 PCR banks will break the state of all swtpms.

If you have suggestions, please let me know.

Regards,

   Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]