Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview

["Jun Koi" <junkoi2004@xxxxxxxxx>]

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