|
xen-devel
Fwd: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology
I forward this to xen-devel and hope it can be useful for somebody.
Cheers,
Quynh
---------- Forwarded message ----------
From: Nguyen Anh Quynh <aquynh@xxxxxxxxx>
Date: Jun 14, 2007 8:01 PM
Subject: Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution
Technology support: Overview
To: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Jun Koi <junkoi2004@xxxxxxxxx>
Cc: xense-devel@xxxxxxxxxxxxxxxxxxx, Kuniyasu Suzaki <k.suzaki@xxxxxxxxxx>
Hi,
I think it is a good idea to have a way to check for the presence of
TXT in your machine without having to look at BIOS setup.
Enclosed is a small module named "txt". You can compile it, and load
it in ("insmod txt.ko"). Check for the presence of TXT by looking for
the message "TXT chipset and all needed capabilities present" in
output of "dmesg". If you don't see that, your machine doesn't support
TXT. See a little README in the attachment.
Note: load the module inside native Linux kernel, but *not* in Xen.
The module code is shamelessly lifted from Joseph's patch :-)
Cheers,
Quynh
On 6/14/07, Cihula, Joseph <joseph.cihula@xxxxxxxxx> wrote:
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
txt.tgz
Description: GNU Zip compressed data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home