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