WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: xense-devel@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology
From: "Jonathan M. McCune" <jonmccune@xxxxxxx>
Date: Thu, 12 Jul 2007 09:40:54 -0400
Cc: joseph.cihula@xxxxxxxxx, junkoi2004@xxxxxxxxx
Delivery-date: Tue, 17 Jul 2007 05:06:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <469542B7.2080008@xxxxxxx>
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: <461E9F7C.70501@xxxxxxx> <469542B7.2080008@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Icedove 1.5.0.10 (X11/20070329)
Hello again,

I made a mistake counting line numbers.  The macro that was causing
problems was SYM_TRAMP_PHYS, which was removed somewhere between
changeset 15331 and 15364.  I have successfully built and used the TXT
patch with changeset 15331.

Sorry for the spam,
-Jon


Jonathan M. McCune wrote:
> Hi Joseph, Jun, Xen developers,
> 
> I'm trying to get this patch to build, but I've encountered some
> difficulty.  Applying the patch to today's tip results in three failures
> which I was able to correct manually.  I also tried an older changeset
> (15369) from the day Jun reported success, and txt-xen-0608_01-xen.patch
> applied with `patch -p1 -F 3`. txt-xen-0608_02-sboot.patch applied
> successfully in both cases.
> 
> I tried both gcc 4.1.2 and 3.4.6.  The failure is the same both ways.
> 
> If I disable the TXT patch (CONFIG_TXT ?= n in Config.mk), Xen builds
> successfully.
> 
> Here is the compilation step that fails:
> 
> gcc -D__ASSEMBLY__ -O2 -fomit-frame-pointer -m32 -march=i686 -DNDEBUG
> -Wall -Wstrict-prototypes -Wno-unused-value
> -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common
> -fno-strict-aliasing -iwithprefix include -Werror -Wno-pointer-arith
> -pipe -I/export/txt/xen-unstable.hg-15369-sboot/xen/include
> -I/export/txt/xen-unstable.hg-15369-sboot/xen/include/asm-x86/mach-generic
> -I/export/txt/xen-unstable.hg-15369-sboot/xen/include/asm-x86/mach-default
> -msoft-float -fno-stack-protector -DCONFIG_X86_PAE=1 -g -D__XEN__
> -DCONFIG_TXT -c head.S -o head.o
> trampoline.S: Assembler messages:
> trampoline.S:49: Error: junk `(trampoline_cpu_started)' after expression
> trampoline.S:51: Error: junk `(idt_48)' after expression
> trampoline.S:52: Error: junk `(gdt_48)' after expression
> make[4]: *** [head.o] Error 1
> make[4]: Leaving directory
> `/export/txt/xen-unstable.hg-15369-sboot/xen/arch/x86/boot'
> make[3]: ***
> [/export/txt/xen-unstable.hg-15369-sboot/xen/arch/x86/boot/built_in.o]
> Error 2
> make[3]: Leaving directory
> `/export/txt/xen-unstable.hg-15369-sboot/xen/arch/x86'
> make[2]: *** [/export/txt/xen-unstable.hg-15369-sboot/xen/xen] Error 2
> make[2]: Leaving directory `/export/txt/xen-unstable.hg-15369-sboot/xen'
> make[1]: *** [install] Error 2
> make[1]: Leaving directory `/export/txt/xen-unstable.hg-15369-sboot/xen'
> make: *** [install-xen] Error 2
> 
> The lines of trampoline.S that trigger this error are not changed by the
> patches, so I'm at a bit of a loss as to what is causing the error. 
> Those three symbols are inside a bootsym() macro which is itself defined
> in trampoline.S.  The macro is not complicated, and makes reference to a
> symbol from head.S (from whence trampoline.S is included).
> 
> Help is greatly appreciated.
> 
> Thanks,
> -Jon
> 
> 
> 
> 
> 
> 
> 
> 
> 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?
> - What to do next to take the advantage of TXT? Any application for it?
> 
> 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.
> 
> 

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

<Prev in Thread] Current Thread [Next in Thread>