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

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

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