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

[Stefan Berger <stefanb@xxxxxxxxxx>]

"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. 

>  
> 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.

   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