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: Wed, 26 Sep 2012 10:39:57 -0400 Message-ID: <506313BD.7020600@jhuapl.edu> References: <50576368.3070007@jhuapl.edu> <1347953926.25803.89.camel@dagon.hellion.org.uk> <5058B07C.1070404@jhuapl.edu> <1348566822.3452.151.camel@zakaz.uk.xensource.com> <5061D2CC.3030108@jhuapl.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4323764241346593571==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org This is a cryptographically signed message in MIME format. --===============4323764241346593571== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010807040300020508080801" This is a cryptographically signed message in MIME format. --------------ms010807040300020508080801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/26/2012 07:46 AM, George Dunlap wrote: > On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante > wrote: >> 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 t= he >> 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 cma= ke >> dependency. > I haven't had a chance to look at your patches in detail (because the > few I've looked at have whitespace damage that Ian mentioned before), > but I as long as the user interface (via xl, config files, &c) is the > same, or comparable, I don't see any reason not to move entirely over > the stubdom model; especially if the process or hybrid models are not > being tested or maintained. It would also simplify the whole system quite a bit. If I am to maintain vtpm I'd like to not have to deal with bugs in the old code. So how should we proceed with this then? Do you all want to remove the vtpm process/hybrid model entirely now or just deprecate it for a while? If we deprecate it do you still want my updates for it? Let me know and I'll provide patches to make it happen either way. The last piece of this puzzle that I haven't figured out is the linux tpm frontend driver. Its not in the main linux tree. Its from the old 2006 vtpm code but it still works. I believe it shipped with the old xen 2.6.18 kernel but now I don't know whats happened to it. I still have a copy we have been porting to newer kernels internally. Should we try to get it in mainline linux? Or maybe provide it in the xen tree as an externally compilable kernel module? There also exists a linux tpm backend driver, but if were only going to support the domain model that is no longer needed and can go away. > -George --------------ms010807040300020508080801 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 KoZIhvcNAQkFMQ8XDTEyMDkyNjE0Mzk1N1owIwYJKoZIhvcNAQkEMRYEFFR6OPocJN67psiJ MAqxT+zYpFB6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBc367hrKrRi01IHT0HPm7XrOb42FjbhYAl 1CT2LEqnX49Ul/p9gO6lJEiBuHE72vebPHZKsWWdl1Qa3IKEnkOiZ7dN9alLsb0s0UZSycfe eLPT58PaZvBsl/DGyFla9qFv86c8yeK1qo2jt9RFkARj8Bpjh4y0lnqVaZXZzjJBXwAAAAAA AA== --------------ms010807040300020508080801-- --===============4323764241346593571== 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 --===============4323764241346593571==--