[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
|
