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

["Jonathan M. McCune" <jonmccune@xxxxxxx>]

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