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