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

[Matthew Fioravante <matthew.fioravante@xxxxxxxxxx>]

On 09/25/2012 05:53 AM, Ian Campbell wrote:
> 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?
the vtpm manager takes control of the tpm and protects the secrets of
vtpms. Each vtpm emulates a tpm for a virtual machine.

There are basically 3 models that have developed over time:
Process model (deprecated?):
This is the old model that was originally with xen which I also provide
bug fixes for. vtpm_manager is the manager that controls the tpm. There
is one vtpmd process launched for each virtual tpm. Both vtpmd and
vtpm_manager are processes in dom0.

Hybrid model (deprecated?):
This was the beginning of our internal development. Now vtpm_manager
runs in dom0, but there is one vtpm-stubdom instance for each vtpm. It
worked via enabling a #define in the vtpm_manager makefile. This was
developed as an incremental stepping stone to the full domain model.

Domain model:
vtpmmgrdom is now a mini-os domain. It  uses pieces of the vtpm_manager
code. vtpm-stubdom is the same as before except now it talks to the
manager dom. The vtpmmgrdom also has a hardware tpm driver and with
iomem passthrough, so that dom0 is completely removed from the vtpm chain.

Internally we only use the domain model because of the higher security
guarantees it provides. It would be much nicer from a maintenance
perspective also to get rid of the process and hybrid models. I don't
think my latest patches to xl even work with the process model anymore.

I don't know if there is anyone who would want to still use vtpms as
processes when the stub domains are now available. Security research
people like the domain model because it guarantees a better separation
of components guaranteed by the hypervisor and doesn't have to trust the
dom0 OS.

If we got rid of the process and hybrid model, then the
tools/vtpm_manager code that is still used could be moved into the
vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
along with the --enable-vtpm stuff in the configure script and the cmake
dependency.

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

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

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