Re: [Xense-devel] RE: [TrouSerS-users] vTPM data seal issue

[Stefan Berger <stefanb@xxxxxxxxxx>]

xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 10/19/2006
08:30:30 AM:

>  
> 
> -----Original Message-----
> From: Hal Finney [mailto:hal.finney@xxxxxxxxx] 
> Sent: Wednesday, October 18, 2006 9:53 PM
> To: Osborn, Justin D.
> Cc: xense-devel@xxxxxxxxxxxxxxxxxxx;
> trousers-users@xxxxxxxxxxxxxxxxxxxxx; vincent.r.scarlata@xxxxxxxxx
> Subject: Re: [TrouSerS-users] vTPM data seal issue
> 
> > That's neat that you got that to work. I've been interested in
> experimenting with Xen and TPM but I've 
> > had trouble getting Xen to run at all on my Thinkpad. Maybe the
> xen-unstable version would work better. 
> > What kernel are you using?
> 
> Xen-unstable works with kernel 2.6.16.29 (which has the tpm_tis driver
> for TPM v. 1.2 support).
> 
> > One thing I don't understand is how the PCRs are shared between
the
> various VMs. I wonder if the idea 
> > is that user code doesn't talk to the "real" PCRs,
at all, rather Xen
> makes up a set of fake PCRs for each
> > VM. The real PCRs are only used to measure Xen. Then I think
most TPM
> operations wouldn't even touch the 
> > real TPM. If you seal and unseal, it is Xen which is maintaining
its
> virtual PCRs, does the crypto, and 
> > decides if the unseal will work. Xen protects the user's secrets
using
> its virtual TPM code, and all of 
> > Xen's secrets are protected by the real TPM. Something like this,
> anyway. I need to learn more about how 
> > all this will work.
> 
> Actually, you're right.  The vTPM PCRs are just a buffer in the
memory
> of vtpmd.  Right now they are just defined to be zero on initialization.
> The original IBM vTPM paper says that vTPM PCRs 1-8 should be the
same
> as the physical TPM's PCRs, but from what I can tell people were in

The treatment of the lower PCRs that we describe there
basically relays a TPM_PCRRead() originating in a VM to the hardware TPM
for those PCRs that are configured as 'mapped'. So the PCRs 0-7 for example
show the current state of the hardware TPM's PCR register 0-7 because they
are 'mapped'. There are also measurement lists (taken by the BIOS or the
Linux Integrity Measurement Architecture) associated with each PCR which
also have to be relayed into the VM. This can all be done in drivers and
should not require changes to applications or the TSS.

The support of mapping PCRs and measurement lists
tries to solve the problem of attesting to virtualized systems and helping
to find the hardware core root of trust. And, yes, there's disagreement
on how to do this.

The problem with the mapping of PCRs is how to deal
with signatures for quotes. We currently have the virtual TPM sign the
complete quote, although logically it does not own the mapped PCRs. For
unmodified OSes running inside a VM where one does not necessarily make
changes to drivers, this isn't practial to do. There, if one wants to see
the core root of trust, it's probably practical to challenge the VM that
owns the hardware TPM.

> disagreement on that so right now they're all
set to zero.

> 
> Speaking of which, here's a question for the vTPM developers:  Is
there
> code out there to load the vTPM PCRs (1-8) with the values from the
> physical TPM?  I'm about to (attempt to) write that, and it'd
be helpful
> if someone's already done it.

With "loading" you probably mean setting
the PCR values to the state of the PCRs at the time of the load. I think
'relaying' is probably better in order to show current state.

 Stefan

> 
> Thanks,
> Justin
> 
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xense-devel
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel