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
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] [Linux] Transfer TPM locality info in theringstr

To: "Stefan Berger" <stefanb@xxxxxxxxxx>, "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] [Linux] Transfer TPM locality info in theringstructure
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Mon, 7 Jan 2008 15:20:41 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, keir@xxxxxxxxxxxxx
Delivery-date: Mon, 07 Jan 2008 15:36:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF4D3220AD.3D1019AC-ON852573C6.0047AD01-852573C6.004E185A@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D936D925018D154694D8A362EEB0892003507B82@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <OF4D3220AD.3D1019AC-ON852573C6.0047AD01-852573C6.004E185A@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchO3Ff2dX8eqHEuR3Kb2jLP5yXHYwCd+JAA
Thread-topic: [Xen-devel] [PATCH] [Linux] Transfer TPM locality info in theringstructure
"Stefan Berger" <stefanb@xxxxxxxxxx> wrote on Friday, January 04, 2008
6:13 AM:
> "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx> wrote on
01/04/2008 04:44:42 AM:
>
> > I think you have lost some of the characteristics of locality in 
> > this mechanism, and while I'm not sure what the precise 
> > ramifications of this are, I am sure that redefining the 
> > characteristics of part of TPM access control mechanism shouldn't be
> > done without careful analysis first. 
> >   
> > 1) Some localities are protected by the chipset, not the software 
> > running on a machine. Locality 4 should only accessible by the 
> > Dynamic Root of Trust for Measurement (DRTM). We currently have no 
> > virtual DRTM, but if we did, it would need to be outside of the VM's
> > OS in order to satisfy even the loosest interpretation of the TCG 
> > DRTM definitions. With the driver specifying the locality, I'm not 
> > sure how you will be able limit access to locality 4 to only this 
> > "external" DRTM. Locality 3 also has special considerations. 
>
> To protect against usage of locality 4 the backend could be used to
check for
> this by either changing it to a value higher than 4 and let the TPM
respond
> with an error message or send an error itself. 
>
> >   
> > 2) TPM Localities are independent from each other. By putting each 
> > locality on it's own page, standard memory protection mechanisms can
> > enable different execution contexts to access the appropriate 
> > locality and no other. In your mechanism, any driver that can access
> > the shared page can set any locality it wants. This forces us down a

> > different use model of having a single trusted driver who sets 
> > locality based on the caller. This leads to a whole different set of
> > questions. How will the trusted driver identify which locality is 
> > appropriate based on the caller? An ioctl won't give you this. A 
> > locality should be assignable to any arbitrary execution context. 
> > What does this all mean for applications that expect the traditional
> > TPM model for localities? 
>
> What this seems to mean is that to properly export the TIS
functionality one 
> driver per locality is needed because otherwise the functionality
offered 
> though the TIS interface is not correctly exported to applications. I
am not 
> sure that different /dev/tpm0..<n> would offer the protection you
mention 
> since this would set locality by just choosing another chardev. 

Per-app/user access can be constrained by ACLs/MAC/etc.

This is the approach that we submitted patches to LKML for.  It requires
the least changes all-around.

> > I think in order to keep the characteristics of the TPM locality 
> > model, we'd need to have 4 shared pages. The Linux driver only needs
> > to support 1 locality, but flexibility to program it to point it at 
> > any locality 0-2 on initialization may be valuable. If a virtual 
>
> Ok, so locality should be a parameter to the vtpm line in the vm
config file. 

This would be sufficient if each VM only needed to access a single
locality.  Given that each VM gets its own virtual TPM, I'm not sure
what the value of single non-zero locality is.  However, I think that it
would be useful to support the model of multiple driver instances within
a VM, each for a different locality.

>
>   Stefan 
>
> > machine wants to use multiple localities, it should have multiple 
> > TPM drivers (one per locality), just like TCG forces for physical 
> > machines. A more privileged piece of code like a VMM or a trusted 
> > reference monitor would use memory protection mechanisms to ensure 
> > each driver can only access the correct locality page. How the 
> > software running in the VM chooses to create these guarantees is up 
> > to them, just like in a physical machine. The locality 4 page would 
> > always be inaccessible to code running in the VM. Only some external
> > DRTM code invoked by a hyper call or something would be able to 
> > access the locality 4 page. 
>
>
> > 
> > -Vinnie Scarlata 
> >   
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Stefan Berger
> > Sent: Thursday, January 03, 2008 6:26 PM
> > To: Cihula, Joseph
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; keir@xxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] [PATCH] [Linux] Transfer TPM locality info 
> > in theringstructure
>
> > 
> > "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote on 01/03/2008
08:48:41 PM:
> > 
> > > On Wednesday, January 02, 2008 11:27 AM, Stefan Berger wrote:
> > > > Transfer TPM locality information in the ring structure. Add a
version
> > > > identifier to the ring structure for possible future extensions.
> > > > 
> > > > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> > > 
> > > Stefan,
> > > 
> > > How do you expect to use the locality value and how would it get
set (to
> > > a non-zero value)? 
> > 
> > The TIS interface offers the different address ranges for using a 
> > locality. A TIS driver can make the localities available through an 
> > ioctl(). A similar ioctl() could exist for the xen driver that 
> > allows the client to choose which locality to use. 
> > 
> > > 
> > > Since the locality value is provided by the originating domain, it
can't
> > > really be "trusted" by the backend without some other type of
> > > validation. 
> > 
> > Except for maybe checking that the value of the locality is not out 
> > of range I don't see what else would need to be checked or is there 
> > maybe some restriction for an OS to let applications use any other 
> > locality than locality '0'? 
> > 
> >    Stefan 
> > 
> > > 
> > > Joe

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel