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

[Stefan Berger <stefanb at linux.vnet.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 4156 bytes --]

On 06/25/2018 12:11 PM, Dr. David Alan Gilbert wrote:
> * Stefan Berger (stefanb(a)linux.vnet.ibm.com) wrote:
>> On 06/25/2018 11:29 AM, Dr. David Alan Gilbert wrote:
>>> * Stefan Berger (stefanb(a)linux.vnet.ibm.com) wrote:
>>>> On 06/25/2018 11:18 AM, Dr. David Alan Gilbert wrote:
>>>>> * Stefan Berger (stefanb(a)linux.vnet.ibm.com) wrote:
>>>>>> 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.
>>>>> Is this something that has to be set at compile time or could it be
>>>>> something chosen at run time (as options to the swtpm command line?)
>>>> It is a compile-time option...
>>> Hmm, that's a shame - I was hoping you'd be able to switch them at
>>> runtime (or at least hide them?) then you can solve the upgrade problem
>>> by running the new swtpm with a flag telling it to hide the new banks.
>>> I hope the ondisk formats for suspend/resume/migration are descriptive
>>> enough to be able to spot an error if you try and load one configured
>>> differently.4
>> The disk format does detect it and refuses to take the state if either there
>> are too many PCR banks or not enough.
> What happens if there are the right number just the wrong type?

The state would be rejected since they are incompatible.

>
>> For the initial version of swtpm we would need to define a default set of
>> PCR banks since the TPM 2 code uses compile time options to build in that
>> set of PCR banks.
> You talk of PCR_Allocate() above as a spec-defined command to hide PCRs
> but with the downside of breaking TPM2_Shutdown - could you implement
> something from the commandline without that downside (I don't know how
> PCR banks work).

Like I said, during swtpm_setup TPM 2 manufacturing the set of PCR banks 
would be chosen and that set would be used by that TPM 2 from then on. 
Though this flexibility is not supported by the code today.


>
>> A future version of swtpm could expose command line options for selecting
>> the PCR banks an instance of swtpm is to run with. libtpms would be compiled
>> with support for all of them and only the chosen subset would be active
>> starting with the initial creation of a particular instance of swtpm.
> Right, that would solve the upgrade half of the problem.

For now I think an initial set of banks to go with would be appropriate.

    Stefan