Re: [PATCH] Upgrade vtpmd to berlios version 0.7.4

[Matthew Fioravante <matthew.fioravante@jhuapl.edu>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3509 bytes --]

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@jhuapl.edu
> Ian.
>


[-- Attachment #1.1.2: Type: text/html, Size: 5409 bytes --]

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 1459 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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