xen-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: |
Thu, 14 Jun 2007 00:42:10 -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: |
Thu, 14 Jun 2007 00:40:17 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<fdaac4d50706132106t46dde456qa8778bf04a3d6204@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: |
<D936D925018D154694D8A362EEB08920019E08E1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <fdaac4d50706130229m18287638h7b3ae84aeb8f4a17@xxxxxxxxxxxxxx> <D936D925018D154694D8A362EEB0892001A5E2CB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <fdaac4d50706132106t46dde456qa8778bf04a3d6204@xxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
AceuOVjqvovvtku1TvuDFJOTUuo+MQAG4Z0A |
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 9:06 PM:
> 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?
/proc/cpuinfo will only tell you if a CPU supports the SMX (GETSEC)
instructions. It will not tell you if the chipset is TXT-capable nor
whether TXT is enabled. If you look at the code in sboot/txt/verify.c
you can see how the supports_smx() function determines if the CPU both
supports and is enabled for TXT. supports_txt() shows how to determine
that the chipset supports it.
> Same question for TPM.
I belive that you can use the ACPI tables to determine if a TPM is
supported. You can also query it using it's fixed MMIO registers.
>
> Thanks,
> Jun
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|