From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: tpm2@lists.01.org, "Kenneth Goldman" <kgoldman@us.ibm.com>,
"Chris Friesen" <chris.friesen@windriver.com>,
"Qi, Yadong" <yadong.qi@intel.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Xu, Quan" <quan.xu@intel.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [Qemu-devel] Choosing PCR banks for swtpm's TPM 2
Date: Mon, 25 Jun 2018 16:59:33 +0100 [thread overview]
Message-ID: <20180625155933.GK18580@redhat.com> (raw)
In-Reply-To: <6adb28e6-85eb-38dc-ad24-99a5daa0f972@linux.vnet.ibm.com>
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 :|
next prev parent reply other threads:[~2018-06-25 15:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-25 15:05 [Qemu-devel] Choosing PCR banks for swtpm's TPM 2 Stefan Berger
2018-06-25 15:18 ` Dr. David Alan Gilbert
2018-06-25 15:22 ` Stefan Berger
2018-06-25 15:29 ` Dr. David Alan Gilbert
2018-06-25 15:54 ` Stefan Berger
2018-06-25 16:11 ` Dr. David Alan Gilbert
2018-06-25 16:23 ` Stefan Berger
2018-06-25 15:25 ` Daniel P. Berrangé
2018-06-25 15:56 ` Stefan Berger
2018-06-25 15:59 ` Daniel P. Berrangé [this message]
2018-06-25 16:08 ` Stefan Berger
2018-06-25 16:10 ` Daniel P. Berrangé
2018-06-25 16:15 ` Stefan Berger
2018-06-25 19:44 ` Stefan Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180625155933.GK18580@redhat.com \
--to=berrange@redhat.com \
--cc=chris.friesen@windriver.com \
--cc=kgoldman@us.ibm.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quan.xu@intel.com \
--cc=stefanb@linux.vnet.ibm.com \
--cc=tpm2@lists.01.org \
--cc=yadong.qi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).