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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

I just realised while looking at your reposting of this that I never
replied here, sorry.

On Tue, 2012-09-18 at 18:33 +0100, Matthew Fioravante wrote:


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

No I don't think it does :-(

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

Right, this was the main bit I was thinking of.

I think what I didn't appreciate is that the stub domains also build
this vtm stuff as well as the drivers, is that right? If we need the
source for stubdoms we might as well have it for vtpmd

Architectural question: Am I right that vtpmd is a host wide daemon for
mediating access to the real TPM while vtpm_managerdom (or one of the
stubdom types?) are responsible for the tpm emulation for a single
domain -- they communicate with vtpmd to get stuff done?

Is there also a stubdom which can take on the vtpmd role?

Removing vtpm_managerdom sounds like a win to me, assuming it is
acceptable to require the use of stubdoms for vtpm functionality. Is it?

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

That's a shame, but unavoidable I suppose.. 

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

Thanks.

Ian.


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