From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Fioravante Subject: Re: [PATCH] Upgrade vtpmd to berlios version 0.7.4 Date: Tue, 18 Sep 2012 13:33:48 -0400 Message-ID: <5058B07C.1070404@jhuapl.edu> References: <50576368.3070007@jhuapl.edu> <1347953926.25803.89.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6271241676353502840==" Return-path: In-Reply-To: <1347953926.25803.89.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org This is a cryptographically signed message in MIME format. --===============6271241676353502840== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050601030502070606050109" This is a cryptographically signed message in MIME format. --------------ms050601030502070606050109 Content-Type: multipart/alternative; boundary="------------010702040904090502060006" This is a multi-part message in MIME format. --------------010702040904090502060006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 kerne= l >> 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. > --------------010702040904090502060006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 09/18/2012 03:38 AM, Ian Campbell wrote:
On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravant=
e wrote:

What will follow soon are updates to vtpmd, vtpm_m=
anager, 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.berli= os.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.

--------------010702040904090502060006-- --------------ms050601030502070606050109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMDkxODE3MzM0OFowIwYJKoZIhvcNAQkEMRYEFMeGK1UGWXEmHJoC sunoiQlCqoHzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAly748IwYjEetIdEZMOHsgUxY4M04LIPcc 6hDSgvDR2QfoEbOWTDWLP4OE3b2YYwo3q0qlfPRvvDDm9SORi9vFVXeKxevgKFCoJenn6adI mtDp4PLfqVdmjyZWddGFjS9bfiqbqz31Je0OqahVbH1fW5ZxRRnl0JI9ALWJx660hgAAAAAA AA== --------------ms050601030502070606050109-- --===============6271241676353502840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6271241676353502840==--