[Xen-devel] Several vtpm patches and workarounds: persistence, stability, tpm_emulator-0.5.1

[Matt Fioravante <Matthew.Fioravante@xxxxxxxxxx>]

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 wanted
to contribute them back to the xen community.

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 all
the keys and data you stored in it.

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.

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.

All of these patches can be applied on top of each other in any order.
$ patch -p1 < patchfile


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 are
included at the end of this email.


==============================
vtpm_manager-hash_error.patch
==============================
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 truncated
when it is written and this results in the hash becoming invalid because
of the extra bits at the end of the file.

This patch adds O_TRUNC to the flags when opening the file.

More details on this issue are in the bug report on bugzilla 
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1488

==============================
vtpm-uuid.patch
==============================
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.

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.

So for example, in your config file you would do something like this
vtpm = [ 'backend=0,uuid=dcdb124b-9fed-4040-b149-dd2dfd8d094c' ]

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.

==============================
vtpm-0.4-persistence.patch
==============================
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.

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

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. 

I imagine several other tpm commands would have this problem as well.

==============================
vtpm-0.5.1.patch
==============================
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.

This patch also defines TPM_STRONG_PERSISTENCE for the new emulator.

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

============================
vtpm_manager and xen hotplug workarounds
============================
Here are some issues I've run into when trying to use vtpm. Note that in
my test cases we were only using vtpms in PVM domains.

It might make sense to add these to a readme or something somewhere
until the hotplug issues are fixed.

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 memory
file does not exist, which is normal when xen creates a new vtpm
instance.

2-Q) When I start vtpm_managerd it starts spamming output to the console
forever and gives the following error:
ERROR[VTPM]: [Hotplug Listener]: Hotplug Listener can't read from ipc.
Errono = 0. Aborting... 
2-A) Sometimes the hotplug scripts and the fifos they use to
communicate 
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=10 bs=1 count=4 if=/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.

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. 
Perform the same set of steps in 2-A.

vtpm_manager-hash_error.patch
Description: Text Data

vtpm-uuid.patch
Description: Text Data

vtpm-0.4-persistence.patch
Description: Text Data

vtpm-0.5.1.patch
Description: Text Data

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel