This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Several vtpm patches and workarounds: persistence, stabi

To: Matt Fioravante <Matthew.Fioravante@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Several vtpm patches and workarounds: persistence, stability, tpm_emulator-0.5.1
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 21 Aug 2009 17:33:15 +0100
Delivery-date: Fri, 21 Aug 2009 09:33:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1250870533.13535.1.camel@anonelbe>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoieRaWdNQOkfBqR+u6ThoWb2eEHQAA/5Jl
Thread-topic: [Xen-devel] Several vtpm patches and workarounds: persistence, stability, tpm_emulator-0.5.1
User-agent: Microsoft-Entourage/
Thanks. Can you provide a signed-off-by line for these patches? Then at
least some of them can go into the Xen repository.

 -- Keir

On 21/08/2009 17:02, "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
> 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.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>