|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
On 6/14/07, Cihula, Joseph <joseph.cihula@xxxxxxxxx> wrote: 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! Certainly I need to look at TXT spec. A question: can /proc/cpuinfo tell me my machine has TXT enabled? If not, is there any way to detect TXT from Linux without inspecting BIOS setup? Same question for TPM. Thanks, Jun _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |