From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQITH-0000Ts-RF for qemu-devel@nongnu.org; Mon, 01 Feb 2016 12:41:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQITE-0007JD-J1 for qemu-devel@nongnu.org; Mon, 01 Feb 2016 12:41:03 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:40581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQITE-0007I7-AR for qemu-devel@nongnu.org; Mon, 01 Feb 2016 12:41:00 -0500 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 1 Feb 2016 10:40:58 -0700 Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 6B01D3E4003B for ; Mon, 1 Feb 2016 10:40:55 -0700 (MST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u11HetxF32374922 for ; Mon, 1 Feb 2016 17:40:55 GMT Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u11HesTn024927 for ; Mon, 1 Feb 2016 12:40:54 -0500 Received: from e39.co.us.ibm.com (e39.boulder.ibm.com [9.17.249.49]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u11HemZY023786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Feb 2016 12:40:49 -0500 Message-Id: <201602011740.u11HemZY023786@d01av04.pok.ibm.com> Received: from localhost by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 1 Feb 2016 10:40:47 -0700 Received: from /spool/local by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Mon, 1 Feb 2016 17:40:43 -0000 In-Reply-To: From: "Stefan Berger" Date: Mon, 1 Feb 2016 12:40:45 -0500 References: <1451921002-8263-1-git-send-email-stefanb@us.ibm.com> <20160120145839.GB13215@redhat.com> <201601201523.u0KFNwOH000398@d01av04.pok.ibm.com> <20160120154209.GE13215@redhat.com> <201601202016.u0KKGKpL031707@d01av01.pok.ibm.com> <20160121114035.GD2446@work-vm> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00611F4A85257F4C_=" Subject: Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , "Daniel P. Berrange" Cc: mst@redhat.com, qemu-devel@nongnu.org, jb613w@att.com, quan.xu@intel.com, silviu.vlasceanu@gmail.com, hagen.lauer@huawei.com --=_alternative 00611F4A85257F4C_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="US-ASCII" Stefan Berger/Watson/IBM wrote on 01/21/2016 07:31:10 AM: >=20 > "Dr. David Alan Gilbert" wrote on 01/21/2016=20 > 06:40:35 AM: > >=20 > > >=20 > > > There is one issue in case of resume of a snapshot. If the=20 > permanent state=20 > > > of the TPM is modified during snapshotting, like ownership is=20 > taken of the=20 > > > TPM, the state, including the owner password, is written into the=20 plain=20 > > > file. Then the VM is shut down. Once it is restarted (not a resume=20 from a=20 > > > snapshot), the TPM's state will be relected by what was done during=20 the=20 > > > run of that snapshot. So this is likely undesirable. Now the only=20 way=20 > > > around this seems to be that one needs to know the reason for why=20 the=20 > > > state blobs were pushed into the vTPM. In case of a snapshot, the=20 writing=20 > > > of the permanent state into a file may need to be suppressed, while=20 on a=20 > > > VM resume and resume from migration operation it needs to be written = into=20 > > > the TPM's state file. > >=20 > > I don't understand that; are you saying that the ioctl's dont provide=20 all > > the information that's included in the state file? >=20 > No. Running a snapshot does not change the state of the VM image=20 > unless one takes another snapshot. The vTPM has to be behave the=20 > same way, meaning that the state of the vTPM must not be overwritten > while in a snapshot. However, the vTPM needs to know that it's=20 > running a snapshot whose state is 'volatile'. >=20 > Example:=20 > 1) A VM is run and VM image is in state VM-A and vTPM is in state=20 > vTPM-A. The VM is shut down and VM is in state VM-A and vTPM is in=20 > state vTPM-A. >=20 > 2) The VM runs a snapshot and VM image is in state VM-B and vTPM is=20 > in state B. The user takes ownership of the vTPM, which puts the=20 > vTPM into state vTPM-B2. VM is shut down and with that all VM image=20 > state is discarded. Also the VTPM's state needs to be discarded. >=20 > 3) The VM is run again and the VM image is in state VM-A and the=20 > vTPM must be in state vTPM-A from 1). However, at the moment the=20 > vTPM wold be in state vTPM-B2 from the last run of the snapshot=20 > since the state was written into the vTPM's state file. Following tests that I have done (again, on the virt-manager level) the=20 above in 3) is not correct. Instead the following seems to be what is=20 happening and with that the current vTPM implementation is correct as=20 well: 3) The VM is run again and the VM image is in state VM-B (!) and the vTPM=20 is also in state vTPM-B from running 2). Following the run of a VM snapshot, the next time the VM will be started,=20 the VM image will in the state when that snapshort terminated. Following=20 this, the vTPM's (permanent) state can always be written into the same=20 file.=20 Regards, Stefan --=_alternative 00611F4A85257F4C_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII" Stefan Berger/Watson/IBM wrote on 01/21/2016 07:31:10 AM:

>
> "Dr. David Alan Gilbert" <dgilbert@re= dhat.com> wrote on 01/21/2016
> 06:40:35 AM:
> = >
> > >
> > > There is one issue in case of re= sume of a snapshot. If the
> permanent state
> > > of the TPM is modified during s= napshotting, like ownership is
> taken of the
> > > TPM, the state, including the o= wner password, is written into the plain
> > > file. Then the VM is shut down. Once it i= s restarted (not a resume from a
> > > snapshot), the TPM's state will be relec= ted by what was done during the
> > > run of that snapshot. So this is likely = undesirable. Now the only way
> > > around this seems to be that one needs to k= now the reason for why the
> > > state blobs were pushed into the vTPM. In ca= se of a snapshot, the writing
> > > of the permanent state into a file may need = to be suppressed, while on a
> > > VM resume and resume from migration operation= it needs to be written into
> > > the TPM's state file.
> >
&= gt; > I don't understand that; are you saying that the ioctl's dont provide all
> > the information that's included in the state file?=
>
> No. Running a snapshot doe= s not change the state of the VM image
> unless one takes another sn= apshot. The vTPM has to be behave the
> same way, meaning that the s= tate of the vTPM must not be overwritten
> while in a snapshot. Howev= er, the vTPM needs to know that it's
> running a snapshot whose stat= e is 'volatile'.
>
> Example: &= nbsp;
> 1) A VM is run and VM image is= in state VM-A and vTPM is in state
> vTPM-A. The VM is shut down and VM is in stat= e VM-A and vTPM is in
> state vTPM-A.
>
> 2) T= he VM runs a snapshot and VM image is in state VM-B and vTPM is
> in state B. The user takes ownership of the vTPM, which puts the <= br>> vTPM into state vTPM-B2. VM is shut down and with that all VM image
> state is discarded. Also the VTPM's state needs to be discarded.
>
> 3) The VM is run again and t= he VM image is in state VM-A and the
> vTPM must be in state vTPM-A = from 1). However, at the moment the
> vTPM wold be in state vTPM-B2 = from the last run of the snapshot
> since the state was written into= the vTPM's state file.

Following tes= ts that I have done (again, on the virt-manager level) the above in 3) is not correct. Instead the following seems to be what is happening and with that the current vTPM implementation is correct as well:

3) The VM is run again and t= he VM image is in state VM-B (!) and the vTPM is also in state vTPM-B from running 2).<= br>
Following the run of a VM snapshot, the next time the VM will be started, the VM image will in the state when that snapshort terminated. Following this, the vTPM's (permanent) state can always be written into the same file.

Regards,=
   Stefan

--=_alternative 00611F4A85257F4C_=--