Re: [PATCH] Upgrade vtpmd to berlios version 0.7.4

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

[-- Attachment #1.1: Type: text/plain, Size: 3071 bytes --]

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
>>> <matthew.fioravante@jhuapl.edu> 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 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.
>>> 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?
> 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 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?
> 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 to
>> support the domain model that is no longer needed and can go away.
> Indeed.
>
> Ian.
>



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