Re: [Xen-devel] [PATCH v2 0/9] vTPM new ABI, extensions

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 12/04/2012 01:55 PM, Matthew Fioravante wrote:
> Have you given any thought to the vtpm auto-shutdown semantics? I'd like to 
> preserve that if at all possible. Is the only conflicting patch there patch 8?
> 

#8 should be the only patch that conflicts, although I have not tested
that the shutdown works as expected after #5. I think the shutdown key
in Xenstore is the best solution for this issue (and don't really have
a strong preference for weak function vs a waitqueue).

> On 11/30/2012 09:49 AM, Daniel De Graaf wrote:
>> This patch queue goes on top of Matthew Fioravante's [VTPM v5 0/7]
>> series. While some of the patches have been posted before, all have
>> been cleaned up a bit.
>>
>> [PATCH 1/9] stubdom: Change vTPM shared page ABI
>>     * Removed unneeded reconfiguration pieces
>>     * Removed feature-protocol-v2 xenstore key references
>>
>> [PATCH 2/9] stubdom/vtpm: Support locality field
>>     * Add distinct patch file instead of patching a patch
>>     * Comment on future use of the locality field
>>
>> [PATCH 3/9] stubdom/vtpm: correct the buffer size returned by
>>     * New patch
>>
>> [PATCH 4/9] stubdom/vtpm: Add locality-5 PCRs
>>     * New patch
>>
>> [PATCH 5/9] stubdom/vtpm: Allow repoen of closed devices
>>     * This used to use Reconfigure, but has been changed to use
>>       the Closed states similar to blkback
>>
>> [PATCH 6/9] stubdom/vtpm: make state save operation atomic
>>     * Avoid hardcoded maximum saved state size
>>     * Better debug/error messages
>>
>> [PATCH 7/9] stubdom/grub: send kernel measurements to vTPM
>>     * Use PolarSSL SHA1 function
>>     * Use byteswap.h functions
>>
>> [PATCH 8/9] stubdom/vtpm: support multiple backends
>>     * Split into its own patch so it can be excluded if
>>       automatic vTPM shutdown is required
>>
>> [PATCH 9/9] stubdom/vtpm: Add PCR pass-through to hardware TPM
>>     * New patch, RFC; an alternative to hwinitpcrs
> 
> 


-- 
Daniel De Graaf
National Security Agency

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