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 11:58:08 -0400 Message-ID: <50632610.2070709@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> <506313BD.7020600@jhuapl.edu> <1348672896.19176.54.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4660389707984739233==" Return-path: In-Reply-To: <1348672896.19176.54.camel@zakaz.uk.xensource.com> 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: George Dunlap , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org This is a cryptographically signed message in MIME format. --===============4660389707984739233== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080806010300010705070902" This is a cryptographically signed message in MIME format. --------------ms080806010300010705070902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/26/2012 11:21 AM, Ian Campbell wrote: > On Wed, 2012-09-26 at 15:39 +0100, Matthew Fioravante wrote: >> 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 separati= on >>>> 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 c= make >>>> 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 mainta= in >> 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 whil= e? >> If we deprecate it do you still want my updates for it? > I'm happy for you to just remove the hybrid and process variants. > > I think if anyone is really attached to those then it is up to them to > step up and maintain them, if someone does turn up then they can always= > resurrect it from the VCS history and start from there. Ok then in that case, ignore the vtpmd and vtpm_manager patches I sent before. The only ones that are not applicable are the mini-os patches and the libxl patches. The stubdoms are coming soon. I'd like to rework them so that the vtpm_manager code is just included directly into vtpmmgrdom. >> 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 x= en >> 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? > This is the preferred approach. > >> Or maybe provide it in the >> xen tree as an externally compilable kernel module? > We generally try and avoid that these days. > >> There also exists a linux tpm backend driver, but if were only going t= o >> support the domain model that is no longer needed and can go away. > Indeed. > > Ian. > --------------ms080806010300010705070902 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 KoZIhvcNAQkFMQ8XDTEyMDkyNjE1NTgwOFowIwYJKoZIhvcNAQkEMRYEFIHcL3PmTkYCSQdV i/cw/2XZzSGFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBPPlkJaJuqw9KMxuGr4WN6eSrgJd9o1AIn VUUM54WUViH58eN2bjVCaxY/QPAL00l3eg/m784iHqyExYPWwpmaWz/T7602xmOxaBcFA7SH wLu1Kbq0hZWbG8g0ybHJz+IJPV/t80nsOgoibrnyBSs2Bi6E+hBS+Fqp7WaKdyKF3QAAAAAA AA== --------------ms080806010300010705070902-- --===============4660389707984739233== 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 --===============4660389707984739233==--