From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Fioravante Subject: Re: Several vtpm patches and workarounds: persistence, stability, tpm_emulator-0.5.1 Date: Fri, 21 Aug 2009 15:46:09 -0400 Message-ID: <1250883969.13535.6.camel@anonelbe> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1675749066==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org --===============1675749066== Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-QiAtELsg+hW9ISwqOIcQ" --=-QiAtELsg+hW9ISwqOIcQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Signed-off-by: Matt Fioravante On Fri, 2009-08-21 at 12:33 -0400, Keir Fraser wrote: > Thanks. Can you provide a signed-off-by line for these patches? Then at > least some of them can go into the Xen repository. >=20 > -- Keir >=20 > On 21/08/2009 17:02, "Matt Fioravante" > wrote: >=20 > > We are using xen and vtpm at JHU APL for a project and ran into many > > problems. I've had to develop several patches and workarounds and wante= d > > to contribute them back to the xen community. > >=20 > > Here are a few patches that will make the xen vtpm system more stable > > and allow you to have persistent vtpms. In other words you can reboot a > > domU and it will come back up with the same vtpm instance and retain al= l > > the keys and data you stored in it. > >=20 > > Also included is a patch that ports vtpm to tpm_emulator-0.5.1. The new > > emulator has a lot of bug fixes over the old 0.4 and is recommended if > > you want a working vtpm implementation. This port is incomplete, so > > please see the details on that patch before applying it. > >=20 > > Some of these are actual bug fixes while others are hacks/workarounds. > > Becuase of this, they have been broken into several patches to assist > > the developers in choosing which they want to integrate. With these > > patches we have been successfully able to use persistent vtpms for > > signing certificates. > >=20 > > All of these patches can be applied on top of each other in any order. > > $ patch -p1 < patchfile > >=20 > >=20 > > Finally, there are also some bugs in the xen hotplug system and the > > vtpm_manager. Sometimes the manager can get into a corrupted state and > > it will cease to work properly. Workarounds for some of the problems ar= e > > included at the end of this email. > >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > vtpm_manager-hash_error.patch > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > There is a bug in the vtpm_manager that has to do with hashing and > > saving the NVM memory files (vtpm_dm_%d.data). The file is not truncate= d > > when it is written and this results in the hash becoming invalid becaus= e > > of the extra bits at the end of the file. > >=20 > > This patch adds O_TRUNC to the flags when opening the file. > >=20 > > More details on this issue are in the bug report on bugzilla > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1488 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > vtpm-uuid.patch > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > Right now xen will create a new vtpm instance everytime you start up a > > domU, even if you specify the instance parameter in your config file. > > Each vtpm instance is then given a uuid and the vtpm.db file maps > > instance numbers to uuid numbers. > >=20 > > This patch is a hack that lets you explicitly set the uuid of your vtpm > > instance. Everytime you boot up your domU now the vtpm will get that > > uuid and thus it will always get the same vtpm instance number instead > > of being generated a new one. > >=20 > > So for example, in your config file you would do something like this > > vtpm =3D [ 'backend=3D0,uuid=3Ddcdb124b-9fed-4040-b149-dd2dfd8d094c' ] > >=20 > > If you are using this patch then be sure to also use the hash_error > > patch, otherwise you may see checksum failed messages when booting > > your domain and the vtpm tries to read the NVM file. These 2 patches > > were made separate because the first is a bug fix and this one is more > > of a hack. > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > vtpm-0.4-persistence.patch > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > This patch is only needed if you want to continue using > > tpm_emulator-0.4. It is not necessary if you are going to use the > > tpm_emulator-0.5.1 patch. > >=20 > > This patch will add > > #define TPM_STRONG_PERSISTENCE > > which will make the tpm_emulator send a TPM_SaveState command after > > every tpm command it executes. This is needed because some commands lik= e > > TPM_TakeOwnership do not send the TPM_SaveState command on their own. > > The tpm_emulator will only request the manager to save its state when > > this TPM command is sent. > >=20 > > So in short without this patch, if you took ownership of your vtpm and > > then rebooted the domU, the the change in state would not be saved and > > your vtpm would come back unowned again. > >=20 > > I imagine several other tpm commands would have this problem as well. > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > vtpm-0.5.1.patch > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > This patch will port vtpm to use tpm_emulator-0.5.1 > > The newer version of the emulator contains several bug fixes, one that > > we were seeing in our use of vtpm. > >=20 > > This patch also defines TPM_STRONG_PERSISTENCE for the new emulator. > >=20 > > A couple of important notes about this patch: > > -This has only been tested on PVM domU's. In theory it should work for > > HVM but I have not tried it at all and can guarantee nothing. > > -All the relevant changes in tools/vtpm/vtpm.patch have been ported to > > tpm_emulator-0.5.1. > > -None of the changes in tpm_emulator.patch have been ported. In > > particular this means the BUILD_EMULATOR option, which as I understand > > lets you use the tpm_emulator in dom0 for a machine that does > > not have a real hardware TPM does not work. This functionality should b= e > > easy to add though because the new emulator already comes with a kernel > > module interface. > > -No considerations were made for the VTPM_MULTI_VM feature (which is > > supposedly unfinished). This patch may or may not break any progress > > made on that feature. > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > vtpm_manager and xen hotplug workarounds > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Here are some issues I've run into when trying to use vtpm. Note that i= n > > my test cases we were only using vtpms in PVM domains. > >=20 > > It might make sense to add these to a readme or something somewhere > > until the hotplug issues are fixed. > >=20 > > 1-Q) When I boot my domU with a vtpm for the first time I get > > the following error message in the vtpm_managerd output > > Loading NVM. > > Sending LoadNVM command > > ERROR[VTPM]: Failed to load NVM > > .INFO[VTPM]: [VTPM Listener]: VTPM Listener waiting for messages. > > Reading LoadNVM header > > 1-A) This is ok. This message comes up when the vtpm non-volatile memor= y > > file does not exist, which is normal when xen creates a new vtpm > > instance. > >=20 > > 2-Q) When I start vtpm_managerd it starts spamming output to the consol= e > > forever and gives the following error: > > ERROR[VTPM]: [Hotplug Listener]: Hotplug Listener can't read from ipc. > > Errono =3D 0. Aborting... > > 2-A) Sometimes the hotplug scripts and the fifos they use to > > communicate=20 > > get in a corrupted state. We need to clear all the fifos. > > 1) First, stop all of the vms that have vtpms. > > 2) Kill the vtpm_managerd > > 3) Search for vtpm processes. > > #ps -ef | grep vtpm > > You may see processes that look like the following. If you do > > not see any then skip ahead to the next step. > > /bin/bash /etc/xen/scripts/vtpm add > > dd skip=3D10 bs=3D1 count=3D4 if=3D/var/vtpm/fifos/to_console.fifo > > /usr/bin/vtpmd > > First, kill any of the dd processes, and then run ps again. Most if > > not all of the /etx/xen/scripts/vtpm processes should have quit. > > Kill any of the remaining scripts/vtpm and vtpmd processes. > > Note that after killing some of of the "vtpm add" processes > > new "vtpm remove" processes may get spawned which you will > > also need to kill. > > 4) Delete all of the fifos and socks > > #rm /var/vtpm/fifos/* > > #rm /var/vtpm/socks/* > > 5) Remove the lock files if they exist > > # rm -rf /var/run/xen-hotplug/vtpm* > > 6) Now start up the vtpm_managerd again, it should start without errors= . > > 7) Finally, you should be able to boot up the vms again without any > > problems. > >=20 > > 3-Q) When I start a domU that has a vtpm it hangs in the > > pause state and will not boot. If I wait long enough it will quit and > > tell me that the Hotplug scripts are not working. > > 3-A) This occurs when we have stale lock files that did not get removed > > properly.=20 > > Perform the same set of steps in 2-A. > >=20 >=20 >=20 --=-QiAtELsg+hW9ISwqOIcQ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHZzCCA5kw ggMCoAMCAQICBD/xkcEwDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpI VUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTA5MDcxNzE1MDgwOVoXDTEyMDcxNzE1MzgwOVowZjEL MAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxlMTUwFgYDVQQLEw9W UE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50ZTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAyzeGk9zPA33fsB3uvk/Izs9GGHCpHI8bzXdBIVg6++S+jK53PoaWgmtS Lr/c732ea1zPR6ACymwAWON+U5rB+VJAUZ4l/p0T3LZjE1KqnbQJ+pgb+WAmBtdrxrtky61E9HD8 dO70x37+ejhunpF9OuSU5MnOPmMx6ranvahUsOsCAwEAAaOCAYkwggGFMAsGA1UdDwQEAwIFIDAb Bg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyULAwEBAQIEChIIMDAxMDQyNjEw WAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3JyZXNwb25kaW5nIHRvIHRoaXMgY2Vy dGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4wKAYDVR0RBCEwH4EdTWF0dGhldy5GaW9y YXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBHoEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYD VQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RDQTEOMAwGA1UEAxMFQ1JMNDkwHwYDVR0jBBgwFoAU CDUpmxH52EU2CyWmF2EJMB1yqeswHQYDVR0OBBYEFO3ziReJlElP3ilaLQ5gwsg0RlgoMAkGA1Ud EwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAMOY3Zf6g x3gv/fDd11czh2Daj+8NExx/2Le3c88gfDVhPVgVX5S52EjeFbK5yVP0Xlm82vRADO47dTA2PKbp p50rJcAZrl5bg5tQ/WbLAaRITCtOJWVVKXD9V7X2o3Z/IM2op3hb4mmDXSDS+Hzn0Jd2mAXl4iHP fI0pXlXqA9QwggPGMIIDL6ADAgECAgQ/8ZHAMA0GCSqGSIb3DQEBBQUAMC8xCzAJBgNVBAYTAlVT MQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RDQTAeFw0wOTA3MTcxNTA4MDlaFw0xMjA3 MTcxNTM4MDlaMGYxCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBlBlb3Bs ZTE1MBYGA1UECxMPVlBOR3JvdXAtQklTRENBMBsGA1UEAxMUTWF0dGhldyBFIEZpb3JhdmFudGUw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALFMg8OajmArzkacH4guEdbB4NrwivrfbBhNtDag O/y2dqpgYl6PJa/tlQgpzTuFKWk41A274FRXIZPuqmFP/18M1hjIszV+k8xf96Jf9/8aO+iMEKou bymRX8jmEPbMTTx2X3peMGzmBjzP7ReQR9QFdbucivJRvM0zmkxZQg5bAgMBAAGjggG2MIIBsjAL BgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwOTA3MTcxNTA4MDlagQ8yMDExMDgyMzE5MzgwOVow GwYNKwYBBAGzJQsDAQEBAQQKFghmaW9yYW1lMTAbBg0rBgEEAbMlCwMBAQECBAoSCDAwMTA0MjYx MFgGCWCGSAGG+mseAQRLDElUaGUgcHJpdmF0ZSBrZXkgY29ycmVzcG9uZGluZyB0byB0aGlzIGNl cnRpZmljYXRlIG1heSBoYXZlIGJlZW4gZXhwb3J0ZWQuMCgGA1UdEQQhMB+BHU1hdHRoZXcuRmlv cmF2YW50ZUBqaHVhcGwuZWR1MFIGA1UdHwRLMEkwR6BFoEOkQTA/MQswCQYDVQQGEwJVUzEPMA0G A1UEChMGSkhVQVBMMQ8wDQYDVQQLEwZCSVNEQ0ExDjAMBgNVBAMTBUNSTDQ5MB8GA1UdIwQYMBaA FAg1KZsR+dhFNgslphdhCTAdcqnrMB0GA1UdDgQWBBSaCdoMqQJy4FAcQNlbA6POsBWu5TAJBgNV HRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjEDAgSwMA0GCSqGSIb3DQEBBQUAA4GBAI8y4/qy rQUec2HW6pTST0S8ACG1mAq8sNXGBkqe/ro5T5/E52pOThUDlhEWdRT1OAjPGHHDHBqDOLXxeib0 RxDbfriq1ZGqowXC9z7hjwxDL1qwptO1w53VOvdRBqelASJv+h3ZkSrKDH9fz2UpPuVJDBP1COsK Soe/NA62T5n7MYIBzzCCAcsCAQEwNzAvMQswCQYDVQQGEwJVUzEPMA0GA1UEChMGSkhVQVBMMQ8w DQYDVQQLEwZCSVNEQ0ECBD/xkcAwCQYFKw4DAhoFAKCB7zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA4MjExOTQ2MDlaMCMGCSqGSIb3DQEJBDEWBBQqz2hX5RKl XyDXZPCafUPf0iZznTBGBgkrBgEEAYI3EAQxOTA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZK SFVBUEwxDzANBgNVBAsTBkJJU0RDQQIEP/GRwTBIBgsqhkiG9w0BCRACCzE5oDcwLzELMAkGA1UE BhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBAgQ/8ZHBMA0GCSqGSIb3DQEB AQUABIGAJnDDFyxH5fan9KEYPyI0hfYaeLI9Bq+/iYfWoviAtTlaivg8yropqQAj+eI3fjH+2NP+ 6IQrDec8chEYd/Ts/4PEMWD0Mmt4JkyLCKqOeIOidzmrEQQZwRk/pJM5zkYxNH9iIcHG4HdUfGA7 xVbgdrcdnAUDO7AvaXRpeVOBBPUAAAAAAAA= --=-QiAtELsg+hW9ISwqOIcQ-- --===============1675749066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1675749066==--