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: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology

To: "Jun Koi" <junkoi2004@xxxxxxxxx>
Subject: RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Wed, 13 Jun 2007 10:07:52 -0700
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Wed, 13 Jun 2007 10:05:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <fdaac4d50706130229m18287638h7b3ae84aeb8f4a17@xxxxxxxxxxxxxx>
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: <AceqLrHw9k0eE1VGTGivJ8LlKk1LqA==> <D936D925018D154694D8A362EEB08920019E08E1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <fdaac4d50706130229m18287638h7b3ae84aeb8f4a17@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcetnUcDb6E7KDZdT7urXoJjhEQS8gAPYB1w
Thread-topic: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Jun Koi <mailto:junkoi2004@xxxxxxxxx> scribbled on Wednesday, June 13,
2007 2:29 AM:
> Hi Joseph,
> 
> On 6/9/07, Cihula, Joseph <joseph.cihula@xxxxxxxxx> wrote:
>> Attached is a preliminary patch that adds Intel(r) Trusted Execution
>> Technology (Intel(r) TXT) support to Xen.  Intel(r) TXT was formerly
>> known by the codename LaGrande Technology (LT).
>> 
>> This version of the patch (the previous version was posted last year)
>> re-factors the Intel(r) TXT code into a separate module/binary that
>> is passed as the 'kernel' to GRUB and which then launches Xen itself
>> (after having performed the measured launch).
>> 
>> This patch supports all of the Xen processor modes
>> (32bit/32bitPAE/64bit) and supports multi-core/thread systems.  It
>> will run on either an Intel LT SDV3 or on the Intel(r) TXT TEP
>> (Technology Enabling Platform) from MPC. 
>> 
>> 
>> Intel(r) TXT in Brief:
>> ----------------------
>> o  Provides dynamic root of trust for measurement (DRTM)
>> o  DMA protection (on SDV3/TEP platforms only)
>> o  Data protection in case of improper shutdown
>> 
>> For more information, see http://www.intel.com/technology/security/.
>> This site also has a link to the Intel(r) TXT Preliminary
>> Architecture Specification. 
>> 
>> 
>> Overview of Patch Functionality:
>> --------------------------------
>> o  Measured Launch.  If the processor is detected as being
>> TXT-capable and enabled then the code will attempt to perform a
>> measured launch.  If the measured launch process fails (processor is
>> not capable, TXT is not enabled, missing SINIT, corrupted data,
>> etc.)) then it will fall-through to a non-TXT boot of Xen. 
>> 
> 
> This is interesting. Do I understand correctly as in below?
> 
> - sboot runs in VMX root-operation, then it boots Xen. Then Xen is in
> non-root operation.

Not exactly.  Only the APs get put into VMX mode and this is so they can
respond to the INIT-SIPI-SIPI SMP boot sequence; and then VMX is turned
off after they are awakened.  The BSP does not enable VMX until Xen
enables it.

> - After that, Xen switches back to root-operation. Life goes on as it
> is now. 
> 
> If that is the case, then Xen can access the reserved memory by sboot,
> right? So in case Xen is compromised, the secrets saved in the
> reserved memory can be leaked?

This is correct, however.  sboot and Xen are in the same protection
domain.  Since VT does not support nested/recursive virtualization,
there is really no way to protect sboot from Xen.  But I don't see this
as a problem either.  sboot does not have any secrets (at least not at
this time) and could just as easily have been a part of Xen (it was in
the last year's patch) if we didn't want to generalize it.

> Perhaps I understand something wrong, as the whole things dont make
> sense to me. 

The best way to think of Intel(r) TXT is as a technology that provides a
dynamic (i.e. at the time it is invoked) root of trust, or "safe place
to stand".  So it allows you to start some code in a "secure"/measured
environment and then that code can establish any further protections it
needs.

> 
> Thanks,
> Jun

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