[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4



On 09/18/2012 03:38 AM, Ian Campbell wrote:
On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravante wrote:
What will follow soon are updates to vtpmd, vtpm_manager, xm, xl,
mini-os, and new vtpm and vtpm manager stub domains.
No need to update xm any more, it is deprecated in 4.2.
I have just one small patch for xm coming. You can decide if you want to accept or not. Its a small addition.

Who or what is/are Berlios? Are they (actively) maintaining the vTPM?
The berlios tpm emulator is what vtpm is based off of.
http://tpm-emulator.berlios.de/

Essentially vtpmd and vtpm-stubdom (coming in a patch) are just small patches for the tpm emulator to allow it to run in the vtpm framework. The older version of the emulator required more invasive patching. The newer one lets you set some function pointers to override functionality such as saving and loading to disk, making it much easier and simpler to modify it to become a vtpm.

Perhaps we should consider making this stuff an external dependency
rather than importing it into our code base? This could be done either
as a simple dependency (i.e. require vtpm to be installed before
building) or as a repo cloned during build (like how we handle qemu and
seabios etc).

This might be workable. The vtpm system has 2 mini-so stubdoms and 3 mini-os tpm drivers. Does mini-os/stubdom have a nice way of building stuff out of tree? It doesn't appear so at the moment. The whole stubdom setup is basically one large monolithic makefile. vtpm domains also require building openssl, polarssl, and libgmp in the stubdom cross root.

Should the tpm drivers should be included in mini-os for potential use by other projects or also kept in their own separate tree? They are GPL drivers so maybe out of tree makes more sense.

vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms as processes in dom0, instead of separate domains) could easily be moved out of tree. They are just binaries installed on the system.

vtpm support for xm/xl probably has to stay in xen. Unless someone plans on making a plugin architecture for xl. There are also the hotplug scripts, but those go away with xl.

The first patch I'd like to submit upgrades vtpmd to version 0.7.4

This patch does the following:
-add checks to configure to check for cmake (required by berlios 0.7.4)
Is the model with cmake that it is required on all the end systems
building the project (like make), or is it only needed on the project
maintainer's system (like autoconf/make)?
Its the equivalent of running a configure script, so its needed on end systems. Also you have to download and patch the tpm emulator before running cmake, so if we did want to avoid its usage on end systems we would have to ship the entire source code of the patched emulator.

-removes all of the 0.5.1 patches
-adds a single patch for 0.7.4
-cleans up the makefile, should work for parallel make (avoiding
version.h discussion from august 2012)
-builds vtpmd to use berlios 0.7.4
-Remoed the tpm_emualtor build option. berlios itself provides a kernel
module if you want to use it in dom0 to emulate the physical tpm.
Is there going to be an associated documentation update/refresh?
Right now I don't have a formal doc but I want to write one. I'm looking into getting some time to do this.

Signed of by: Matthew Fioravante matthew.fioravante@xxxxxxxxxx
Ian.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.