Jonathan M. McCune
2007-Apr-12 21:07 UTC
[Xen-devel] 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
Cihula, Joseph
2007-Apr-12 21:52 UTC
RE: [Xense-devel] [RFC][PATCH][UPDATED] Intel(R) LaGrande Technology support
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
Jonathan M. McCune
2007-Jul-11 20:51 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology
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
2007-Jul-12 13:40 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology
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
Cihula, Joseph
2007-Jul-12 16:54 UTC
[Xense-devel] RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology
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