Xen devel - Apr 2007 - Re: [Xense-devel] [RFC][PATCH][UPDATED] Intel(R) LaGrande Technology support

Hello,

Has any more work been done on this front?  The message below is
from Sept. 2006.  In particular, the LT/TXT Technology Enabling
Platform (TEP) is now available from MPC Corp.  Where can one
obtain an appropriate AC SINIT module (i.e., like
lpg_sinit_20050831_pae.auth.bin below)?  I would like to begin
using Xen with TXT support.

Thanks,
-Jon




This patch adds SMP support to the previous version.  Since that has not
been merged I have included it in this patch.  This should apply cleanly
to the tip.  Below is the text of the original submittal, slightly
updated.

Attached is a preliminary patch that adds Intel(R) LaGrande Technology
(LT) (Safer Mode Extensions - SMX) support to Xen.  While there are
still several enhancements needed for complete support, we feel that it
is sufficiently complete for an initial public posting to expose to the
community.


LaGrande Technology in Brief:
-----------------------------
o  Provides dynamic root of trust for measurement (DRTM)
o  DMA protection
o  Data protection in case of improper shutdown

For more information on LT, see the Intel LaGrande Technology website:
http://www.intel.com/technology/security/.
This site also has a link to the LT preliminary specification (an
updated version that reflects the functionlaity of this code will be
available later this week).


The LT functionality this code adds is:
---------------------------------------
o  Measured Launch.  If the processor is detected as being LT-capable
and enabled then the code will attempt to perform a measured launch.  If
the processor is (not capable) or (capable but not enabled) or (capable
and enabled but the launch process fails (missing SINIT, corrupted data,
etc.)) then it will fall-through to a non-LT boot.
o  Teardown of measured environment.  When Xen exits the LT environment
will be torn down properly.
o  Reset data protection.  LT HW prevents access to secrets if the
system is reset without clearing them from memory (as part of a LT
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 LT memory ranges.  LT reserves certain regions of RAM
for its use and also defines several MMIO regions.  These regions are
protected from use by any domains (including dom0).  Note that there a
sub-regions of the MMIO space that are left accessible to dom0 (LT
public configuration space, TPM localities 0,1).


Patch breakdown:
----------------
Config.mk - add INTEL_SMX build config
xen/Rules.mk - adds ''-DCONFIG_SMX'' compile flag if INTEL_SMX=y
xen/arch/x86/Makefile - add arch/x86/smx dir to build
xen/arch/x86/boot/x86_32.S - hook startup to launch LT
environmentxen/arch/x86/setup.c - initialize fixmap entries for LT
config reg space
xen/arch/x86/domain_build.c - protect LT private config space
xen/arch/x86/e820.c - support for E820_PROTECTED mem type
xen/arch/x86/hvm/vmx/vmx.c - support new LT/VMX IA32_FEATURE_CONTROL_MSR
flag
xen/arch/x86/mm.c - support for E820_PROTECTED mem type
xen/arch/x86/setup.c - hook to reserve LT RAM regions and initialize
fixmap entries for LT config reg space
xen/arch/x86/shutdown.c - hook shutdown to teardown LT environment
xen/common/domctl.c - prevent XEN_DOMCTL_iomem_permission from being
able to map LT private config space
xen/include/asm-x86/cpufeature.h - adds new SMX feature flag
xen/include/asm-x86/e820.h - export print_e820_memory_map()
xen/include/asm-x86/fixmap.h - adds fixmap entries for LT config reg
space
xen/include/asm-x86/msr.h - adds new VMX and SMX MSR flags
xen/include/asm-x86/processor.h - adds new CR4 SMX flag
xen/include/public/hvm/e820.h - add E820_PROTECTED mem type
xen/arch/x86/smx/Makefile - self explanatory
xen/arch/x86/smx/acmod.c - LT Authenticated Code (AC) module support fns
xen/arch/x86/smx/early_printk.c - serial printk() for early in boot
process
xen/arch/x86/smx/errors.c - error parsing/display fns
xen/arch/x86/smx/mtrrs.c - MTRR handling for AC module launch
xen/arch/x86/smx/smx.c - main LT/SMX fns and entry points
xen/arch/x86/smx/tpm.c - basic TPM support fns
xen/include/asm-x86/smx/* - headers for SMX/LT fns


This code has been developed and tested on Intel Software Development
Platform (SDP) 3 systems (available under NDA via the Intel Premier
Support channel).  It will be updated to work with the LT Technology
Enabling Platform (TEP) that will be publicly available this fall.


Instructions for use:
---------------------
o  By default, the functionality is disabled in the build.  It can be
enabled by changing the INTEL_SMX flag to ''y'' in Config.mk.
o  The SINIT AC module (available with SDP3 systems) must be added to
the grub.conf boot config as the last module, e.g.:
        ...
        module /initrd-2.6.16.13-xen.img
        module /lpg_sinit_20050831_pae.auth.bin
o  Progress of the LT launch process is indicated via debug printk''s to
COM1 (hardcoded).  These appear before the normal "(XEN)" output and
are
prefixed by "SMX:".  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


Caveats / Notes:
----------------
o  x86_64 is not supported yet (IA64 does not support LT at this time).
o  The code only measures the hypervisor (and its command line), which
is not the complete TCB.
o  It doesn''t cap (extend with invalid value) the dynamic TPM PCRs when
the LT environment is torn down.  Instead it disables the BIOS reboot
option so that any shutdown/reboot will have to reset the platform and
the TPM.
o  TPM locality 2 is not protected.  The defined behavior for access to
unpermitted localities is for reads to return 0xff''s and writes to be
dropped.  This will require mapping pages from locality 3 or 4 into the
locality 2 range.
o  No DMA protection has been implemented in this patch.  SDP3 only
supports the NoDMA table for DMA protection and this will be superseded
by VT-d.  VT-d support for LT will be added after it is added for the
general case.

These limitations will be addressed in subsequent patches.

There was a presentation on the code at the Xen Summit.  More
information on LT is available at
http://www.intel.com/technology/security/.  Comments and feedback are
welcome at any time.


Joseph Cihula
(Linux) Software Security Architect
Open Source Technology Center
Intel Corp.

*** These opinions are not necessarily those of my employer ***


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

Jonathan M. McCune <mailto:jonmccune@cmu.edu> scribbled on Thursday,
April 12, 2007 2:07 PM:
> Hello,
> 
> Has any more work been done on this front?  The message below is
> from Sept. 2006.  In particular, the LT/TXT Technology Enabling
> Platform (TEP) is now available from MPC Corp.  Where can one
> obtain an appropriate AC SINIT module (i.e., like
> lpg_sinit_20050831_pae.auth.bin below)?  I would like to begin
> using Xen with TXT support.
> 
> Thanks,
> -Jon
> 
A very timely email indeed.  We are putting the finishing touches on a
re-design of the TXT support patch per feedback that we received last
year.  In addition to breaking the code out into a separate module that
executes before Xen, it will include support for both 32 and 64 bit Xen
and fix some of the TBD''s.  We''re expecting to have it ready
in the week
or two (cross-your-fingers before/during the Xen Summit).

As to getting the SINIT AC Module for the MPC TEP system, the person
here who works with MPC tells me that it should be on a CD included with
the system.  If this is not the case, please let me know, but I will
send it to you just in case.

Joe
> 
> 
> 
> This patch adds SMP support to the previous version.  Since that has
> not 
> been merged I have included it in this patch.  This should apply
> cleanly 
> to the tip.  Below is the text of the original submittal, slightly
> updated.
> 
> Attached is a preliminary patch that adds Intel(R) LaGrande Technology
> (LT) (Safer Mode Extensions - SMX) support to Xen.  While there are
> still several enhancements needed for complete support, we feel that
> it 
> is sufficiently complete for an initial public posting to expose to
> the 
> community.
> 
> 
> LaGrande Technology in Brief:
> -----------------------------
> o  Provides dynamic root of trust for measurement (DRTM)
> o  DMA protection
> o  Data protection in case of improper shutdown
> 
> For more information on LT, see the Intel LaGrande Technology website:
> http://www.intel.com/technology/security/.
> This site also has a link to the LT preliminary specification (an
> updated version that reflects the functionlaity of this code will be
> available later this week).
> 
> 
> The LT functionality this code adds is:
> ---------------------------------------
> o  Measured Launch.  If the processor is detected as being LT-capable
> and enabled then the code will attempt to perform a measured launch. 
> If 
> the processor is (not capable) or (capable but not enabled) or
> (capable 
> and enabled but the launch process fails (missing SINIT, corrupted
> data, 
> etc.)) then it will fall-through to a non-LT boot.
> o  Teardown of measured environment.  When Xen exits the LT
> environment 
> will be torn down properly.
> o  Reset data protection.  LT HW prevents access to secrets if the
> system is reset without clearing them from memory (as part of a LT
> 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 LT memory ranges.  LT reserves certain regions of RAM
> for its use and also defines several MMIO regions.  These regions are
> protected from use by any domains (including dom0).  Note that there a
> sub-regions of the MMIO space that are left accessible to dom0 (LT
> public configuration space, TPM localities 0,1).
> 
> 
> Patch breakdown:
> ----------------
> Config.mk - add INTEL_SMX build config
> xen/Rules.mk - adds ''-DCONFIG_SMX'' compile flag if
INTEL_SMX=y
> xen/arch/x86/Makefile - add arch/x86/smx dir to build
> xen/arch/x86/boot/x86_32.S - hook startup to launch LT
> environmentxen/arch/x86/setup.c - initialize fixmap entries for LT
> config reg space
> xen/arch/x86/domain_build.c - protect LT private config space
> xen/arch/x86/e820.c - support for E820_PROTECTED mem type
> xen/arch/x86/hvm/vmx/vmx.c - support new LT/VMX
> IA32_FEATURE_CONTROL_MSR 
> flag
> xen/arch/x86/mm.c - support for E820_PROTECTED mem type
> xen/arch/x86/setup.c - hook to reserve LT RAM regions and initialize
> fixmap entries for LT config reg space
> xen/arch/x86/shutdown.c - hook shutdown to teardown LT environment
> xen/common/domctl.c - prevent XEN_DOMCTL_iomem_permission from being
> able to map LT private config space
> xen/include/asm-x86/cpufeature.h - adds new SMX feature flag
> xen/include/asm-x86/e820.h - export print_e820_memory_map()
> xen/include/asm-x86/fixmap.h - adds fixmap entries for LT config reg
> space
> xen/include/asm-x86/msr.h - adds new VMX and SMX MSR flags
> xen/include/asm-x86/processor.h - adds new CR4 SMX flag
> xen/include/public/hvm/e820.h - add E820_PROTECTED mem type
> xen/arch/x86/smx/Makefile - self explanatory
> xen/arch/x86/smx/acmod.c - LT Authenticated Code (AC) module support
> fns xen/arch/x86/smx/early_printk.c - serial printk() for early in
> boot 
> process
> xen/arch/x86/smx/errors.c - error parsing/display fns
> xen/arch/x86/smx/mtrrs.c - MTRR handling for AC module launch
> xen/arch/x86/smx/smx.c - main LT/SMX fns and entry points
> xen/arch/x86/smx/tpm.c - basic TPM support fns
> xen/include/asm-x86/smx/* - headers for SMX/LT fns
> 
> 
> This code has been developed and tested on Intel Software Development
> Platform (SDP) 3 systems (available under NDA via the Intel Premier
> Support channel).  It will be updated to work with the LT Technology
> Enabling Platform (TEP) that will be publicly available this fall.
> 
> 
> Instructions for use:
> ---------------------
> o  By default, the functionality is disabled in the build.  It can be
> enabled by changing the INTEL_SMX flag to ''y'' in
Config.mk.
> o  The SINIT AC module (available with SDP3 systems) must be added to
> the grub.conf boot config as the last module, e.g.:
>         ...
>         module /initrd-2.6.16.13-xen.img
>         module /lpg_sinit_20050831_pae.auth.bin
> o  Progress of the LT launch process is indicated via debug
printk''s
> to 
> COM1 (hardcoded).  These appear before the normal "(XEN)" output
and
> are 
> prefixed by "SMX:".  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
> 
> 
> Caveats / Notes:
> ----------------
> o  x86_64 is not supported yet (IA64 does not support LT at this
> time). 
> o  The code only measures the hypervisor (and its command line), which
> is not the complete TCB.
> o  It doesn''t cap (extend with invalid value) the dynamic TPM PCRs
> when 
> the LT environment is torn down.  Instead it disables the BIOS reboot
> option so that any shutdown/reboot will have to reset the platform and
> the TPM.
> o  TPM locality 2 is not protected.  The defined behavior for access
> to 
> unpermitted localities is for reads to return 0xff''s and writes to
be
> dropped.  This will require mapping pages from locality 3 or 4 into
> the 
> locality 2 range.
> o  No DMA protection has been implemented in this patch.  SDP3 only
> supports the NoDMA table for DMA protection and this will be
> superseded 
> by VT-d.  VT-d support for LT will be added after it is added for the
> general case.
> 
> These limitations will be addressed in subsequent patches.
> 
> There was a presentation on the code at the Xen Summit.  More
> information on LT is available at
> http://www.intel.com/technology/security/.  Comments and feedback are
> welcome at any time.
> 
> 
> Joseph Cihula
> (Linux) Software Security Architect
> Open Source Technology Center
> Intel Corp.
> 
> *** These opinions are not necessarily those of my employer ***
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.xensource.com
http://lists.xensource.com/xen-devel

Jonathan M. McCune <mailto:jonmccune@cmu.edu> scribbled on Thursday,
July 12, 2007 9:41 PM:
> 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.
Glad to hear it.  In the original patch I forgot to mention which
changeset it was based on (15200).  I''m glad to see that it works on a
bit later version as well.
> 
> 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-gener
ic
>>
-I/export/txt/xen-unstable.hg-15369-sboot/xen/include/asm-x86/mach-defau
lt
>> -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.
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel