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

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

Jun Koi <mailto:junkoi2004@xxxxxxxxx> scribbled on Friday, June 15, 2007
3:32 AM:
> Hi Joseph,
> 
> I compiled TXT patch with the latest unstable, and it works well. I
> mean my machine boot wtih /sboot.gz in grub file, and Xen runs like
> normal. Sweet!
> 
> Few questions:
> - Now, how can I confirm that TXT is actully running on my machine?

The easiest way to confirm that the measured launch succeeded is to
examine the serial output for "SBOOT: measured launch succeeded".

You could also write a kernel module that read the TXTCR_STS register
(offset 0) in the public space (private space is blocked in all domains)
and if the senter_done_sts (bit 0) bit is set then the launch succeeded.

Lastly, you could read (or quote) PCRs 17 and 18 to verify that they
contain the expected hashes for SINIT and sboot, respectively.

> - What to do next to take the advantage of TXT? Any application for
> it? 

TXT is not really exposed to applications per se.  Rather it provides a
trusted foundation for building additional protections and functionality
on.  In this case, it provides a known-good environment for launching
Xen.  So anything that runs on TXT/Xen automatically receives the
benefits.

> 
> Thanks,
> Jun
> 
> 
> 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. 
>> 
>> o  Teardown of measured environment.  When Xen exits the measured
>> environment will be torn down properly.
>> 
>> o  Reset data protection.  Intel(r) TXT HW prevents access to
>> secrets if the system is reset without clearing them from memory (as
>> part of a TXT teardown).  This code will support this by setting the
>> flag indicating that memory should be so protected during the
>> measured launch and clearing the flag just before teardown.
>> 
>> o  Protection of TXT memory ranges.  Intel(r) TXT reserves certain
>> regions of RAM for its use and also defines several MMIO regions. 
>> These regions (excluding the TXT public configuration space) are
>> protected from use by any domains (including dom0).
>> 
>> 
>> Patch Contents:
>> ---------------
>> txt-xen-0608_01-xen.patch - the changes to Xen for Intel(r) TXT
>> support txt-xen-0608_02-sboot.patch - the new sboot module that
>> performs the measured launch 
>> 
>> 
>> Instructions for use:
>> ---------------------
>> o  By default, the functionality is disabled in the build.  It can be
>> enabled by changing the INTEL_TXT flag to 'y' in Config.mk.
>> 
>> o  The new sboot module must be added as the 'kernel' and xen made a
>> 'module'.  The SINIT AC module (available with SDV3 and TEP systems)
>> must be added to the grub.conf boot config as the last module, e.g.:
>>         title Xen 3.1.0 w/ Intel(r) Trusted Execution Technology
>>                 kernel /sboot.gz
>>                 module /xen.gz dom0_mem=524288 com1=115200,8n1
>>                 module /vmlinuz-2.6.18-xen
>>                 root=/dev/VolGroup00/LogVol00 ro module
>>                 /initrd-2.6.18-xen.img module
>> /lpg_sinit_20050831_pae.auth.bin 
>> 
>> o  Progress of the launch process is indicated via debug printk's to
>> COM1 (hardcoded).  These appear before the normal "(XEN)" output and
>> are prefixed by "SBOOT:".  The code (in early_printk.c) does not
>> initialize the COM port so this needs to be done by GRUB - grub.conf
>>         should have: serial --speed=115200 --unit=0
>>         terminal console serial
>> 
>> 
>> Interesting Items of Note:
>> --------------------------
>> o  A Xen that is not compiled for Intel(r) TXT can still be launched
>> by sboot, however it will not protect any of the TXT memory nor sboot
>> itself.  Further, it will not be able to use any threads or cores
>> beyond the BSP.  And it will hang on reboot/shutdown.
>> 
>> o  A Xen compiled for Intel(r) TXT can be used without sboot and will
>> simply detect that it was not launched in a measured environment and
>> behave as normal. 
>> 
>> o  The patch defines two new E820 types, E820_PROTECTED and
>> E820_MLE_SHARED.  sboot will copy and alter the e820 table provided
>> by GRUB to "reserve" its own memory plus the TXT memory regions. 
>> These are marked as E820_PROTECTED so that the patched Xen code can
>> prevent them from being assigned to dom0.  The E820_MLE_SHARED type
>> is for a single page that sboot reserves for communication (sharing)
>> with Xen.  The patched Xen code will look for this page when parsing
>> the e820 table and uses its presence as the indicator that a
>> measured launch took place (the e820 table is not altered if the
>> measured launch fails for any reason). 
>> 
>> o  sboot is always built 32bit and runs in protected mode without
>> PAE or paging enabled.  sboot lives at (copies itself to) 0x70000. 
>> This seems like a safe location so far, but is not a good long-term
>> location.  We'd like to discuss moving Xen a little higher to allow
>> sboot to live at 0x100000--this is a separate thread.
>> 
>> o  Because a proper teardown requires turning off VMX on every
>> core/thread before executing GETSEC[SEXIT], some changes were made to
>> the Xen shutdown code.  An initial commonization of the reboot and
>> shutdown routines was done so that this new code would only have to
>> be put in one place.  Future patches will commonize the other
>> routines in Xen that shutdown or reboot the system, such that they
>> will also perform a teardown of the measured environment.
>> 
>> o  The code requires that VT be enabled as well as TXT.  This is
>> because the mechanism for bringing up the APs uses VMX to create a
>> mini-VM in order to trap on INIT-SIPI-SIPI.
>> 
>> o  Currently only sboot is measured.  We plan to extend this to xen
>> and dom0 in the future. 
>> 
>> o  The patch doesn't cap (extend with invalid value) the dynamic TPM
>> PCRs when the measured environment is torn down.  This will be added
>> when we have a method for re-entering sboot on shutdown implemented.
>> 
>> o  No DMA protection has been implemented in this patch.  SDV3/TEP
>> only support the NoDMA table for DMA protection and this is
>> superseded by VT-d.  VT-d support will be added shortly, though it
>> will only be available on new platforms. 
>> 
>> 
>> 
>> Comments and feedback are very welcome.  We'd especially like to see
>> a discussion about what changes are required for this code to be
>> merged into the -unstable tree. 
>> 
>> We have many enhancements planned, as well as support for newer TXT
>> Software Development Platforms (SDPs).
>> 
>> 
>> Joseph Cihula
>> Jimmy Wei
>> Shane Wang
>> Zhai Edwin
>> 
>> Open Source Technology Center
>> Intel Corp.
>> 
>> *** These opinions are not necessarily those of my employer ***
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel

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