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

To: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
From: "Jun Koi" <junkoi2004@xxxxxxxxx>
Date: Wed, 13 Jun 2007 18:29:00 +0900
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 02:27:01 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dx3ylW3eSDmmYwwTJd8kCI7filL/oM25iBBKtm1LK0H0aKSFuo9QyS/TpahqVPJxu2C95Vl2SOKExP1Nl4WtLHslhvTYN/QNgREaOC2bPOfWrBVYSdWOBculiJ1VDpvMQI1B/+Ap1F1SQhqfw42iLhjG2SsREvGpmhAxkLg2G0k=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JC/QDM3K11JK8o63CplvdxT7zrI63SQNGPRIshqgY09upEEoanGrHAvj8xcAexdapXodCZvcbIhF+pf7xBGERDSEKsm9DohxJ7j+Ny8Gba/Xa5Y3pdMxTTiYm2v+uyyAAxmkCnB4qmzi7hRpmHN3N9DjBHg3/5HNCseaHg/wFHU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D936D925018D154694D8A362EEB08920019E08E1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.
- 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?

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

Thanks,
Jun

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

<Prev in Thread] Current Thread [Next in Thread>