[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 adds new functionality and support to the
previous version (which was posted two months ago).  It continues to
support the Intel(R) TXT Technology Enabling Platform (TEP) and also
adds support for the newly launched vPro and Intel(R) Q35 Express
chipset -based systems.

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
o  Verification and enforcement of launched environment

For more information, see http://www.intel.com/technology/security/. 
This site also has a link to the Intel(R) TXT Preliminary Architecture
Specification, which has been updated for the new released platforms.


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.  This does not currently support
all exit modes (e.g. shutdown via dom0).

o  Reset data protection.  Intel(R) TXT hardware 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).

o  Intel(R) TXT Launch Control Policy (LCP) tools.  The
sboot/tools/lcptools project contains a set of tools (and basic
documentation) that can be used to create and provision TXT Launch
Control policies.  LCP uses TPM non-volatile storage (TPM NV) to hold a
launch policy, which the SINIT AC module reads and uses to enforce which
measured launched environments (MLEs) (e.g. sboot) can be launched
(based on a SHA-1 hash).  TXT LCP will be documented in a separate
specification to be released shortly.  These tools require a TPM
Software Stack (TSS) that supports the Tspi_NV_* API.  The tip of the
CVS TrouSerS project supports them but the bundled code does not.  This
patch set also include a version of TrouSerS (near the tip) that
supports them.


Patch Contents:
---------------
txt-xen-0828_01-xen.patch - the changes to Xen for Intel(R) TXT support
txt-xen-0608_02_{a,b,c,d}-sboot.patch - the new sboot module that
performs the measured launch (broken into 4 by 'split')
txt-xen-0608_03-sboot-tools.patch - tools for LCP and testing
txt-xen-0608_04-trousers - a version of TrouSerS that supports Tspi_NV_*
API (this is a big attachment and I'm not going to split it, so it may
take a while to get through the mail server)

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 systems that support TXT)
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 no-real-mode 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  Xen's command line must include the 'no-real-mode' option to prevent
Xen from reading the e820 table from BIOS.  The TXT code makes
modifications to the table passed via GRUB that the Xen portions of the
code need.

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.  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 no longer defines new E820 memory types.  It does, however,
add support to Xen for the E820_UNUSABLE type (5) defined in the latest
ACPI spec.  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_UNUSABLE so that the patched Xen code can prevent them from
being assigned to dom0.  The single page that sboot reserves for
communication (sharing) with Xen is marked as reserved and identified by
a UUID at its beginning.  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.  While this
location works functionally, it cannot be protected from dom0 (causes a
fault).  We might be able to map a separate set of pages over this for
dom0, but that seems like a lot of work compared to just moving Xen (and
then sboot) up a bit.

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.  Because the 'shutdown' command
in dom0 does not go through Xen's shutdown routines, it will cause a
hang--'reboot' works fine.  This will be addressed in a future patch,
along with S3/S4 support.

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 near future.

o  Support for the TEP's NoDMA capability has been implemented in this
patch.  NoDMA has been superseded by VT-d and is used by default on the
new TXT platforms.  The VT_D define in sboot/include/config.h is for
when Xen supports VT-d.  At that time this code can be enabled and it
will DMA protect all of the memory until Xen has enabled VT-d
translation for the regions that it cares about.  But enabling it before
Xen has VT-d support will cause dom0 to fail to boot.

o  The sboot/tools/txt-test project is a Linux kernel module that reads
some of the TXT registers and also verifies the memory protections.  It
will also display the sboot boot log, in case a system does not have
serial support.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.