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

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

"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