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

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

[Stefan Berger]

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

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

[Dr. David Alan Gilbert]

* Stefan Berger (stefanb@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?)

Dave
> Regards,
> 
>    Stefan
> 
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Stefan Berger]

On 06/25/2018 11:18 AM, Dr. David Alan Gilbert wrote:
> * Stefan Berger (stefanb@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...

    Stefan

>
> Dave
>> Regards,
>>
>>     Stefan
>>
>>
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>

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

[Daniel P. Berrangé]

On Mon, Jun 25, 2018 at 11:05:55AM -0400, Stefan Berger 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.

Anything that has a risk of needing to change between versions would need
to be tied into the machine type in some way.

> 
> 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,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Dr. David Alan Gilbert]

* Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
> On 06/25/2018 11:18 AM, Dr. David Alan Gilbert wrote:
> > * Stefan Berger (stefanb@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.

Dave

>    Stefan
> 
> > 
> > Dave
> > > Regards,
> > > 
> > >     Stefan
> > > 
> > > 
> > > 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Stefan Berger]

On 06/25/2018 11:29 AM, Dr. David Alan Gilbert wrote:
> * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
>> On 06/25/2018 11:18 AM, Dr. David Alan Gilbert wrote:
>>> * Stefan Berger (stefanb@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.

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.

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.

     Stefan

>
> Dave
>
>>     Stefan
>>
>>> Dave
>>>> Regards,
>>>>
>>>>      Stefan
>>>>
>>>>
>>>>
>>> --
>>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>

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

[Stefan Berger]

On 06/25/2018 11:25 AM, Daniel P. Berrangé wrote:
> On Mon, Jun 25, 2018 at 11:05:55AM -0400, Stefan Berger 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.
> Anything that has a risk of needing to change between versions would need
> to be tied into the machine type in some way.

You mean a machine type like q35? I am not sure how it would be tied 
into QEMU since the swtpm command line options are chosen more or less 
independently of the ones from QEMU.

     Stefan

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

[Daniel P. Berrangé]

On Mon, Jun 25, 2018 at 11:56:24AM -0400, Stefan Berger wrote:
> On 06/25/2018 11:25 AM, Daniel P. Berrangé wrote:
> > On Mon, Jun 25, 2018 at 11:05:55AM -0400, Stefan Berger 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.
> > Anything that has a risk of needing to change between versions would need
> > to be tied into the machine type in some way.
> 
> You mean a machine type like q35? I am not sure how it would be tied into
> QEMU since the swtpm command line options are chosen more or less
> independently of the ones from QEMU.

Yes, each QEMU release introduces a new versioned machine type eg
  q35-2.10,  q35-2.11, q35-2.12, q35-3.0

If anything in QEMU changes which impacts live migraiton/save/restore/etc
then we tie it to the versioned machine type. so q35-3.0 would get the
new default value, and all previous machine types keep the old default
value.

For this to be possible with externally launched swtpm though, would
require some way for QEMU to talk to swtpm to tell it what default
to use for this. I don't know enough about swtpm to have an idea how
practical this is or not.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Stefan Berger]

On 06/25/2018 11:59 AM, Daniel P. Berrangé wrote:
> On Mon, Jun 25, 2018 at 11:56:24AM -0400, Stefan Berger wrote:
>> On 06/25/2018 11:25 AM, Daniel P. Berrangé wrote:
>>> On Mon, Jun 25, 2018 at 11:05:55AM -0400, Stefan Berger 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.
>>> Anything that has a risk of needing to change between versions would need
>>> to be tied into the machine type in some way.
>> You mean a machine type like q35? I am not sure how it would be tied into
>> QEMU since the swtpm command line options are chosen more or less
>> independently of the ones from QEMU.
> Yes, each QEMU release introduces a new versioned machine type eg
>    q35-2.10,  q35-2.11, q35-2.12, q35-3.0
>
> If anything in QEMU changes which impacts live migraiton/save/restore/etc
> then we tie it to the versioned machine type. so q35-3.0 would get the
> new default value, and all previous machine types keep the old default
> value.
>
> For this to be possible with externally launched swtpm though, would
> require some way for QEMU to talk to swtpm to tell it what default
> to use for this. I don't know enough about swtpm to have an idea how
> practical this is or not.

The set of PCR banks a future TPM 2 would be 'manufactured with' would 
be determined by parameters to swtpm_setup. That's when the TPM2 is 
'manufactured' and the certificates are created and written into its 
NVRAM locations. QEMU is not talking to the TPM 2 at this point. So it 
would be parameters passed from libvirt to swtpm_setup that determine 
the set of PCR banks. swtpm itself would get those supplied via command 
line options when invoked by swtpm_setup. If one was to skip over the 
swtpm_setup step, then why not use the swtpm command line options that 
need to be there for swtpm_setup support. Though I think few people will 
use it like that. I would not extend the protocol for this purpose.

    Stefan

>
> Regards,
> Daniel

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

[Daniel P. Berrangé]

On Mon, Jun 25, 2018 at 12:08:34PM -0400, Stefan Berger wrote:
> On 06/25/2018 11:59 AM, Daniel P. Berrangé wrote:
> > On Mon, Jun 25, 2018 at 11:56:24AM -0400, Stefan Berger wrote:
> > > On 06/25/2018 11:25 AM, Daniel P. Berrangé wrote:
> > > > On Mon, Jun 25, 2018 at 11:05:55AM -0400, Stefan Berger 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.
> > > > Anything that has a risk of needing to change between versions would need
> > > > to be tied into the machine type in some way.
> > > You mean a machine type like q35? I am not sure how it would be tied into
> > > QEMU since the swtpm command line options are chosen more or less
> > > independently of the ones from QEMU.
> > Yes, each QEMU release introduces a new versioned machine type eg
> >    q35-2.10,  q35-2.11, q35-2.12, q35-3.0
> > 
> > If anything in QEMU changes which impacts live migraiton/save/restore/etc
> > then we tie it to the versioned machine type. so q35-3.0 would get the
> > new default value, and all previous machine types keep the old default
> > value.
> > 
> > For this to be possible with externally launched swtpm though, would
> > require some way for QEMU to talk to swtpm to tell it what default
> > to use for this. I don't know enough about swtpm to have an idea how
> > practical this is or not.
> 
> The set of PCR banks a future TPM 2 would be 'manufactured with' would be
> determined by parameters to swtpm_setup. That's when the TPM2 is
> 'manufactured' and the certificates are created and written into its NVRAM
> locations. QEMU is not talking to the TPM 2 at this point. So it would be
> parameters passed from libvirt to swtpm_setup that determine the set of PCR
> banks. swtpm itself would get those supplied via command line options when
> invoked by swtpm_setup. If one was to skip over the swtpm_setup step, then
> why not use the swtpm command line options that need to be there for
> swtpm_setup support. Though I think few people will use it like that. I
> would not extend the protocol for this purpose.

Ah so in that case, we would merely require ability to record the desired
PCR setup in the XML, and libvirt would then pass the right args to
swtpm_setup when required.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Dr. David Alan Gilbert]

* Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
> On 06/25/2018 11:29 AM, Dr. David Alan Gilbert wrote:
> > * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
> > > On 06/25/2018 11:18 AM, Dr. David Alan Gilbert wrote:
> > > > * Stefan Berger (stefanb@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?

> 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).

> 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.

Dave

>     Stefan
> 
> > 
> > Dave
> > 
> > >     Stefan
> > > 
> > > > Dave
> > > > > Regards,
> > > > > 
> > > > >      Stefan
> > > > > 
> > > > > 
> > > > > 
> > > > --
> > > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > > > 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Stefan Berger]

On 06/25/2018 12:10 PM, Daniel P. Berrangé wrote:
> On Mon, Jun 25, 2018 at 12:08:34PM -0400, Stefan Berger wrote:
>> On 06/25/2018 11:59 AM, Daniel P. Berrangé wrote:
>>> On Mon, Jun 25, 2018 at 11:56:24AM -0400, Stefan Berger wrote:
>>>> On 06/25/2018 11:25 AM, Daniel P. Berrangé wrote:
>>>>> On Mon, Jun 25, 2018 at 11:05:55AM -0400, Stefan Berger 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.
>>>>> Anything that has a risk of needing to change between versions would need
>>>>> to be tied into the machine type in some way.
>>>> You mean a machine type like q35? I am not sure how it would be tied into
>>>> QEMU since the swtpm command line options are chosen more or less
>>>> independently of the ones from QEMU.
>>> Yes, each QEMU release introduces a new versioned machine type eg
>>>     q35-2.10,  q35-2.11, q35-2.12, q35-3.0
>>>
>>> If anything in QEMU changes which impacts live migraiton/save/restore/etc
>>> then we tie it to the versioned machine type. so q35-3.0 would get the
>>> new default value, and all previous machine types keep the old default
>>> value.
>>>
>>> For this to be possible with externally launched swtpm though, would
>>> require some way for QEMU to talk to swtpm to tell it what default
>>> to use for this. I don't know enough about swtpm to have an idea how
>>> practical this is or not.
>> The set of PCR banks a future TPM 2 would be 'manufactured with' would be
>> determined by parameters to swtpm_setup. That's when the TPM2 is
>> 'manufactured' and the certificates are created and written into its NVRAM
>> locations. QEMU is not talking to the TPM 2 at this point. So it would be
>> parameters passed from libvirt to swtpm_setup that determine the set of PCR
>> banks. swtpm itself would get those supplied via command line options when
>> invoked by swtpm_setup. If one was to skip over the swtpm_setup step, then
>> why not use the swtpm command line options that need to be there for
>> swtpm_setup support. Though I think few people will use it like that. I
>> would not extend the protocol for this purpose.
> Ah so in that case, we would merely require ability to record the desired
> PCR setup in the XML, and libvirt would then pass the right args to
> swtpm_setup when required.

Yes, the user would choose PCR banks or libvirt probes swtpm_setup 
version/command line options and selects a reasonable set for the hash 
algorithms recommended at that time.

    Stefan

>
> Regards,
> Daniel

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

[Stefan Berger]

On 06/25/2018 12:11 PM, Dr. David Alan Gilbert wrote:
> * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
>> On 06/25/2018 11:29 AM, Dr. David Alan Gilbert wrote:
>>> * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
>>>> On 06/25/2018 11:18 AM, Dr. David Alan Gilbert wrote:
>>>>> * Stefan Berger (stefanb@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

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

[Stefan Berger]

On 06/25/2018 11:05 AM, Stefan Berger 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.

Actually that was my interpretation of the specs and from what it looks 
like I was wrong assuming that once PCR_Allocate() was used that 
TPM2_Shutdown(SU_STATE) cannot be used anymore at all. The text is a bit 
ambiguous about it. This command can be sent, but the machine needs to 
be rebooted and with that the TPM 2 reset.

The next issue is that the IBM TSS2 is hard coded for 3 PCR banks and a 
few commands are breaking because of that. Now the solution would be to:

- compile-time disable the SHA512 bank; this will break existing state 
but for as long as it's in preview, I hope this is ok; we cannot easily 
enable SHA512 then in the future.

- swtpm_setup gets a --pcr-banks <PCR banks> option that 
PCR_Allocate()'s the active PCR banks for the swtpm. The default will be 
SHA 1 and SHA 256, which disables the SHA 384 PCR bank; Users can choose 
their banks if they run this command directly. SHA1 and SHA256 seems to 
be a reasonable set of active PCR banks for now.

    Stefan



>
> 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
>
>