WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

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

To: "Osborn, Justin D." <Justin.Osborn@xxxxxxxxxx>
Subject: Re: [Xense-devel] RE: [TrouSerS-users] vTPM data seal issue
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Thu, 19 Oct 2006 11:17:50 -0400
Cc: Hal Finney <hal.finney@xxxxxxxxx>, Kent E Yoder <yoder1@xxxxxxxxxx>, kjhall@xxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx, trousers-users@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 19 Oct 2006 08:18:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <7B95239DDD54E54B9BFA23847142B1EE12CBAE@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx

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
<Prev in Thread] Current Thread [Next in Thread>