Cihula, Joseph
2007-Jun-09 00:39 UTC
[Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Attached is a preliminary patch that adds Intel(r) Trusted Execution Technology (Intel(r) TXT) support to Xen. Intel(r) TXT was formerly known by the codename LaGrande Technology (LT). This version of the patch (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. *** These opinions are not necessarily those of my employer *** _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jun-09 10:00 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
On 9/6/07 01:39, "Cihula, Joseph" <joseph.cihula@intel.com> wrote:> 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.What''s wrong with 0x70000?> 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.It looks like you do your best to avoid real mode. Unfortunately the BP now returns to real mode to do various system initialisation work. Do you need a VMX container for any reason other than to trap INIT-SIPI-SIPI? Possibly we could agree on a higher-level method for cpu online/offline. The Xen changes are largely pretty reasonable I think. It would be nice to know that they are sufficient for the AMD secure boot module also, since we obviously don''t want two sets of changes for the same overall purpose. It''d be nice to have some way of detecting sboot other than through e820 (which can sometimes be a bit random). If you keep the VMX container then maybe CPUID(0x40000000)? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cihula, Joseph
2007-Jun-10 05:42 UTC
RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Keir Fraser <mailto:Keir.Fraser@cl.cam.ac.uk> scribbled on Saturday, June 09, 2007 3:01 AM:> On 9/6/07 01:39, "Cihula, Joseph" <joseph.cihula@intel.com> wrote: > >> 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. > > What''s wrong with 0x70000?I''d prefer not to consume the low 1M region unnecessarily, but most importantly, this region can''t be hidden from dom0. We''d really like to protect the sboot code as though it were part of the hypervisor, since it will be needed on shutdown/S3. However, dom0 requires access to al sub-1M addresses or it faults.>> 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. > > It looks like you do your best to avoid real mode. Unfortunately the > BP now returns to real mode to do various system initialisation work.Do you> need a VMX container for any reason other than to trap INIT-SIPI-SIPI? > Possibly we could agree on a higher-level method for cpuonline/offline. Actually, we''ve already started work on using the real mode trampoline entry point. It was just easier to add the protected mode entry point to get the patch out sooner.> The Xen changes are largely pretty reasonable I think. It would be > nice to know that they are sufficient for the AMD secure boot modulealso,> since we obviously don''t want two sets of changes for the same overallpurpose. Agreed.> It''d be nice to have some way of detecting sboot other than through > e820 (which can sometimes be a bit random). If you keep the VMX > container then maybe CPUID(0x40000000)?The VMX container is only used for the APs, so it would not help the BSP to detect that it was launched from sboot. There is a Intel(r) TXT -specific way to detect this, by reading the chipset registers (though that only detects that a measured launch happened, not that sboot was used). Since the TXT chipset regions will not have to be fixmap''ed once we have the code working to exit into sboot for the shutdown, the shared page seemed the most reasonable way to communicate. It will also be needed to convey the shutdown entry point to Xen.> > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jun-10 09:30 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
On 10/6/07 06:42, "Cihula, Joseph" <joseph.cihula@intel.com> wrote:> Keir Fraser <mailto:Keir.Fraser@cl.cam.ac.uk> scribbled on Saturday, > June 09, 2007 3:01 AM: >> On 9/6/07 01:39, "Cihula, Joseph" <joseph.cihula@intel.com> wrote: >> > I''d prefer not to consume the low 1M region unnecessarily, but most > importantly, this region can''t be hidden from dom0. We''d really like to > protect the sboot code as though it were part of the hypervisor, since > it will be needed on shutdown/S3. However, dom0 requires access to al > sub-1M addresses or it faults.Xen could be moved to 2MB easily enough. But even Xen now has a permanent real-mode mapping at 0x90000. We could protect it by copying the bottom megabyte somewhere else in the physical address space, and translating mapping requests into the copy. This would also protect the BIOS and other stuff which may not get refreshed across a soft reboot.> Actually, we''ve already started work on using the real mode trampoline > entry point. It was just easier to add the protected mode entry point > to get the patch out sooner.So the AP entry point in the shared page will go away?> The VMX container is only used for the APs, so it would not help the BSP > to detect that it was launched from sboot. There is a Intel(r) TXT > -specific way to detect this, by reading the chipset registers (though > that only detects that a measured launch happened, not that sboot was > used). Since the TXT chipset regions will not have to be fixmap''ed once > we have the code working to exit into sboot for the shutdown, the shared > page seemed the most reasonable way to communicate. It will also be > needed to convey the shutdown entry point to Xen.Another issue is that Xen now calls the BIOS to get the e820 map itself, since GRUB was messing it up on some systems. Hence your modified e820 map will, by default, be ignored. Perhaps we could take a multiboot_info feature bit, or add an extra multiboot module, to indicate sboot and to provide shared info? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cihula, Joseph
2007-Jun-12 07:03 UTC
RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Keir Fraser <mailto:Keir.Fraser@cl.cam.ac.uk> scribbled on Sunday, June 10, 2007 2:31 AM:> On 10/6/07 06:42, "Cihula, Joseph" <joseph.cihula@intel.com> wrote: > >> Keir Fraser <mailto:Keir.Fraser@cl.cam.ac.uk> scribbled on Saturday, >> June 09, 2007 3:01 AM: >>> On 9/6/07 01:39, "Cihula, Joseph" <joseph.cihula@intel.com> wrote: >>> >> I''d prefer not to consume the low 1M region unnecessarily, but most >> importantly, this region can''t be hidden from dom0. We''d really >> like to protect the sboot code as though it were part of the >> hypervisor, since it will be needed on shutdown/S3. However, dom0 >> requires access to al sub-1M addresses or it faults. > > Xen could be moved to 2MB easily enough. But even Xen now has a > permanent real-mode mapping at 0x90000. We could protect it by copyingthe> bottom megabyte somewhere else in the physical address space, andtranslating> mapping requests into the copy. This would also protect the BIOS and > other stuff which may not get refreshed across a soft reboot.In order to transition to real mode we will need to stay below 1M, so I think your suggestion of copying it and translating to the copy will turn out to be the best solution to the problem. Plus, if the trampoline code is used after initial boot then it really should be protected from dom0 as well. Will you be making this change?>> Actually, we''ve already started work on using the real mode >> trampoline entry point. It was just easier to add the protected >> mode entry point to get the patch out sooner. > > So the AP entry point in the shared page will go away?Yes, the AP entry point would no longer be needed.>> The VMX container is only used for the APs, so it would not help the >> BSP to detect that it was launched from sboot. There is a Intel(r) >> TXT -specific way to detect this, by reading the chipset registers >> (though that only detects that a measured launch happened, not that >> sboot was used). Since the TXT chipset regions will not have to be >> fixmap''ed once we have the code working to exit into sboot for the >> shutdown, the shared page seemed the most reasonable way to >> communicate. It will also be needed to convey the shutdown entry >> point to Xen. > > Another issue is that Xen now calls the BIOS to get the e820 map > itself, since GRUB was messing it up on some systems. Hence yourmodified> e820 map will, by default, be ignored.As Linux also reads the memory map directly, I expected that we would end up having to modify BIOS''s copy eventually. Looks like perhaps sooner than later. When will this change go into the tree?> Perhaps we could take a multiboot_info feature bit, or add an extra > multiboot module, to indicate sboot and to provide shared info?This would also work. One advantage of the modified e820 table is that I expect that most software that parses it will treat the new types as reserved and so will not use the regions that it marks, even if that software was not specifically modified to recognize the types.> > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jun-12 07:55 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
On 12/6/07 08:03, "Cihula, Joseph" <joseph.cihula@intel.com> wrote:>> Xen could be moved to 2MB easily enough. But even Xen now has a >> permanent real-mode mapping at 0x90000. We could protect it by copying > the >> bottom megabyte somewhere else in the physical address space, and > translating >> mapping requests into the copy. This would also protect the BIOS and >> other stuff which may not get refreshed across a soft reboot. > > In order to transition to real mode we will need to stay below 1M, so I > think your suggestion of copying it and translating to the copy will > turn out to be the best solution to the problem. Plus, if the > trampoline code is used after initial boot then it really should be > protected from dom0 as well. Will you be making this change?I''ll probably get around to it eventually. ;-)>> Another issue is that Xen now calls the BIOS to get the e820 map >> itself, since GRUB was messing it up on some systems. Hence your > modified >> e820 map will, by default, be ignored. > > As Linux also reads the memory map directly, I expected that we would > end up having to modify BIOS''s copy eventually. Looks like perhaps > sooner than later. When will this change go into the tree?It''s in the tree already.>> Perhaps we could take a multiboot_info feature bit, or add an extra >> multiboot module, to indicate sboot and to provide shared info? > > This would also work. One advantage of the modified e820 table is that > I expect that most software that parses it will treat the new types as > reserved and so will not use the regions that it marks, even if that > software was not specifically modified to recognize the types.My problem is: who are we to be selecting new reserved values? It seems kind of risky! At least if you have some more reliable sboot detection method apart from the e820 map, that could then indicate that the new type values definitely have their guaranteed sboot meaning. If all you''re keying off is the e820 map, you''re at risk of misinterpreting any crap that any random bios flings at you on a non-sboot system. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jun Koi
2007-Jun-13 09:29 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Hi Joseph, On 6/9/07, Cihula, Joseph <joseph.cihula@intel.com> 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. >This is interesting. Do I understand correctly as in below? - sboot runs in VMX root-operation, then it boots Xen. Then Xen is in non-root operation. - After that, Xen switches back to root-operation. Life goes on as it is now. If that is the case, then Xen can access the reserved memory by sboot, right? So in case Xen is compromised, the secrets saved in the reserved memory can be leaked? Perhaps I understand something wrong, as the whole things dont make sense to me. Thanks, Jun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cihula, Joseph
2007-Jun-13 17:07 UTC
RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Jun Koi <mailto:junkoi2004@gmail.com> scribbled on Wednesday, June 13, 2007 2:29 AM:> Hi Joseph, > > On 6/9/07, Cihula, Joseph <joseph.cihula@intel.com> 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. >> > > This is interesting. Do I understand correctly as in below? > > - sboot runs in VMX root-operation, then it boots Xen. Then Xen is in > non-root operation.Not exactly. Only the APs get put into VMX mode and this is so they can respond to the INIT-SIPI-SIPI SMP boot sequence; and then VMX is turned off after they are awakened. The BSP does not enable VMX until Xen enables it.> - After that, Xen switches back to root-operation. Life goes on as it > is now. > > If that is the case, then Xen can access the reserved memory by sboot, > right? So in case Xen is compromised, the secrets saved in the > reserved memory can be leaked?This is correct, however. sboot and Xen are in the same protection domain. Since VT does not support nested/recursive virtualization, there is really no way to protect sboot from Xen. But I don''t see this as a problem either. sboot does not have any secrets (at least not at this time) and could just as easily have been a part of Xen (it was in the last year''s patch) if we didn''t want to generalize it.> Perhaps I understand something wrong, as the whole things dont make > sense to me.The best way to think of Intel(r) TXT is as a technology that provides a dynamic (i.e. at the time it is invoked) root of trust, or "safe place to stand". So it allows you to start some code in a "secure"/measured environment and then that code can establish any further protections it needs.> > Thanks, > Jun_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jun Koi
2007-Jun-14 04:06 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
On 6/14/07, Cihula, Joseph <joseph.cihula@intel.com> wrote:> Jun Koi <mailto:junkoi2004@gmail.com> scribbled on Wednesday, June 13, > 2007 2:29 AM: > > Hi Joseph, > > > > On 6/9/07, Cihula, Joseph <joseph.cihula@intel.com> 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. > >> > > > > This is interesting. Do I understand correctly as in below? > > > > - sboot runs in VMX root-operation, then it boots Xen. Then Xen is in > > non-root operation. > > Not exactly. Only the APs get put into VMX mode and this is so they can > respond to the INIT-SIPI-SIPI SMP boot sequence; and then VMX is turned > off after they are awakened. The BSP does not enable VMX until Xen > enables it. > > > - After that, Xen switches back to root-operation. Life goes on as it > > is now. > > > > If that is the case, then Xen can access the reserved memory by sboot, > > right? So in case Xen is compromised, the secrets saved in the > > reserved memory can be leaked? > > This is correct, however. sboot and Xen are in the same protection > domain. Since VT does not support nested/recursive virtualization, > there is really no way to protect sboot from Xen. But I don''t see this > as a problem either. sboot does not have any secrets (at least not at > this time) and could just as easily have been a part of Xen (it was in > the last year''s patch) if we didn''t want to generalize it. > > > Perhaps I understand something wrong, as the whole things dont make > > sense to me. > > The best way to think of Intel(r) TXT is as a technology that provides a > dynamic (i.e. at the time it is invoked) root of trust, or "safe place > to stand". So it allows you to start some code in a "secure"/measured > environment and then that code can establish any further protections it > needs. > > >Thanks! Certainly I need to look at TXT spec. A question: can /proc/cpuinfo tell me my machine has TXT enabled? If not, is there any way to detect TXT from Linux without inspecting BIOS setup? Same question for TPM. Thanks, Jun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cihula, Joseph
2007-Jun-14 07:42 UTC
RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Jun Koi <mailto:junkoi2004@gmail.com> scribbled on Wednesday, June 13, 2007 9:06 PM:> On 6/14/07, Cihula, Joseph <joseph.cihula@intel.com> wrote: >> Jun Koi <mailto:junkoi2004@gmail.com> scribbled on Wednesday, June >> 13, 2007 2:29 AM: >>> Hi Joseph, >>> >>> On 6/9/07, Cihula, Joseph <joseph.cihula@intel.com> 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. >>>> >>> >>> This is interesting. Do I understand correctly as in below? >>> >>> - sboot runs in VMX root-operation, then it boots Xen. Then Xen is >>> in non-root operation. >> >> Not exactly. Only the APs get put into VMX mode and this is so they >> can respond to the INIT-SIPI-SIPI SMP boot sequence; and then VMX is >> turned off after they are awakened. The BSP does not enable VMX >> until Xen enables it. >> >>> - After that, Xen switches back to root-operation. Life goes on as >>> it is now. >>> >>> If that is the case, then Xen can access the reserved memory by >>> sboot, right? So in case Xen is compromised, the secrets saved in >>> the reserved memory can be leaked? >> >> This is correct, however. sboot and Xen are in the same protection >> domain. Since VT does not support nested/recursive virtualization, >> there is really no way to protect sboot from Xen. But I don''t see >> this as a problem either. sboot does not have any secrets (at least >> not at this time) and could just as easily have been a part of Xen >> (it was in the last year''s patch) if we didn''t want to generalize it. >> >>> Perhaps I understand something wrong, as the whole things dont make >>> sense to me. >> >> The best way to think of Intel(r) TXT is as a technology that >> provides a dynamic (i.e. at the time it is invoked) root of trust, >> or "safe place to stand". So it allows you to start some code in a >> "secure"/measured environment and then that code can establish any >> further protections it needs. >> >>> > > Thanks! Certainly I need to look at TXT spec. > > A question: can /proc/cpuinfo tell me my machine has TXT enabled? If > not, is there any way to detect TXT from Linux without inspecting BIOS > setup?/proc/cpuinfo will only tell you if a CPU supports the SMX (GETSEC) instructions. It will not tell you if the chipset is TXT-capable nor whether TXT is enabled. If you look at the code in sboot/txt/verify.c you can see how the supports_smx() function determines if the CPU both supports and is enabled for TXT. supports_txt() shows how to determine that the chipset supports it.> Same question for TPM.I belive that you can use the ACPI tables to determine if a TPM is supported. You can also query it using it''s fixed MMIO registers.> > Thanks, > Jun_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nguyen Anh Quynh
2007-Jun-14 11:05 UTC
Fwd: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
I forward this to xen-devel and hope it can be useful for somebody. Cheers, Quynh ---------- Forwarded message ---------- From: Nguyen Anh Quynh <aquynh@gmail.com> Date: Jun 14, 2007 8:01 PM Subject: Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview To: "Cihula, Joseph" <joseph.cihula@intel.com>, Jun Koi <junkoi2004@gmail.com> Cc: xense-devel@lists.xensource.com, Kuniyasu Suzaki <k.suzaki@aist.go.jp> Hi, I think it is a good idea to have a way to check for the presence of TXT in your machine without having to look at BIOS setup. Enclosed is a small module named "txt". You can compile it, and load it in ("insmod txt.ko"). Check for the presence of TXT by looking for the message "TXT chipset and all needed capabilities present" in output of "dmesg". If you don''t see that, your machine doesn''t support TXT. See a little README in the attachment. Note: load the module inside native Linux kernel, but *not* in Xen. The module code is shamelessly lifted from Joseph''s patch :-) Cheers, Quynh On 6/14/07, Cihula, Joseph <joseph.cihula@intel.com> wrote:> Jun Koi <mailto:junkoi2004@gmail.com> scribbled on Wednesday, June 13, > 2007 9:06 PM: > > On 6/14/07, Cihula, Joseph <joseph.cihula@intel.com> wrote: > >> Jun Koi <mailto:junkoi2004@gmail.com> scribbled on Wednesday, June > >> 13, 2007 2:29 AM: > >>> Hi Joseph, > >>> > >>> On 6/9/07, Cihula, Joseph <joseph.cihula@intel.com> 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. > >>>> > >>> > >>> This is interesting. Do I understand correctly as in below? > >>> > >>> - sboot runs in VMX root-operation, then it boots Xen. Then Xen is > >>> in non-root operation. > >> > >> Not exactly. Only the APs get put into VMX mode and this is so they > >> can respond to the INIT-SIPI-SIPI SMP boot sequence; and then VMX is > >> turned off after they are awakened. The BSP does not enable VMX > >> until Xen enables it. > >> > >>> - After that, Xen switches back to root-operation. Life goes on as > >>> it is now. > >>> > >>> If that is the case, then Xen can access the reserved memory by > >>> sboot, right? So in case Xen is compromised, the secrets saved in > >>> the reserved memory can be leaked? > >> > >> This is correct, however. sboot and Xen are in the same protection > >> domain. Since VT does not support nested/recursive virtualization, > >> there is really no way to protect sboot from Xen. But I don''t see > >> this as a problem either. sboot does not have any secrets (at least > >> not at this time) and could just as easily have been a part of Xen > >> (it was in the last year''s patch) if we didn''t want to generalize it. > >> > >>> Perhaps I understand something wrong, as the whole things dont make > >>> sense to me. > >> > >> The best way to think of Intel(r) TXT is as a technology that > >> provides a dynamic (i.e. at the time it is invoked) root of trust, > >> or "safe place to stand". So it allows you to start some code in a > >> "secure"/measured environment and then that code can establish any > >> further protections it needs. > >> > >>> > > > > Thanks! Certainly I need to look at TXT spec. > > > > A question: can /proc/cpuinfo tell me my machine has TXT enabled? If > > not, is there any way to detect TXT from Linux without inspecting BIOS > > setup? > > /proc/cpuinfo will only tell you if a CPU supports the SMX (GETSEC) > instructions. It will not tell you if the chipset is TXT-capable nor > whether TXT is enabled. If you look at the code in sboot/txt/verify.c > you can see how the supports_smx() function determines if the CPU both > supports and is enabled for TXT. supports_txt() shows how to determine > that the chipset supports it. > > > Same question for TPM. > > I belive that you can use the ACPI tables to determine if a TPM is > supported. You can also query it using it''s fixed MMIO registers. > > > > > Thanks, > > Jun > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jun Koi
2007-Jun-15 02:01 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
On 6/14/07, Nguyen Anh Quynh <aquynh@gmail.com> wrote:> I forward this to xen-devel and hope it can be useful for somebody. > > Cheers, > Quynh > > > ---------- Forwarded message ---------- > From: Nguyen Anh Quynh <aquynh@gmail.com> > Date: Jun 14, 2007 8:01 PM > Subject: Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution > Technology support: Overview > To: "Cihula, Joseph" <joseph.cihula@intel.com>, Jun Koi <junkoi2004@gmail.com> > Cc: xense-devel@lists.xensource.com, Kuniyasu Suzaki <k.suzaki@aist.go.jp> > > > Hi, > > I think it is a good idea to have a way to check for the presence of > TXT in your machine without having to look at BIOS setup. > > Enclosed is a small module named "txt". You can compile it, and load > it in ("insmod txt.ko"). Check for the presence of TXT by looking for > the message "TXT chipset and all needed capabilities present" in > output of "dmesg". If you don''t see that, your machine doesn''t support > TXT. See a little README in the attachment. > > Note: load the module inside native Linux kernel, but *not* in Xen. > > The module code is shamelessly lifted from Joseph''s patch :-) >This module is helpful, and it can detect TXT on my machine. Thanks! Jun. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jun Koi
2007-Jun-15 10:32 UTC
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
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@intel.com> 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. > > *** These opinions are not necessarily those of my employer *** > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cihula, Joseph
2007-Jun-17 08:54 UTC
RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Jun Koi <mailto:junkoi2004@gmail.com> scribbled on Friday, June 15, 2007 3:32 AM:> 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?The easiest way to confirm that the measured launch succeeded is to examine the serial output for "SBOOT: measured launch succeeded". You could also write a kernel module that read the TXTCR_STS register (offset 0) in the public space (private space is blocked in all domains) and if the senter_done_sts (bit 0) bit is set then the launch succeeded. Lastly, you could read (or quote) PCRs 17 and 18 to verify that they contain the expected hashes for SINIT and sboot, respectively.> - What to do next to take the advantage of TXT? Any application for > it?TXT is not really exposed to applications per se. Rather it provides a trusted foundation for building additional protections and functionality on. In this case, it provides a known-good environment for launching Xen. So anything that runs on TXT/Xen automatically receives the benefits.> > Thanks, > Jun > > > On 6/9/07, Cihula, Joseph <joseph.cihula@intel.com> 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. >> >> *** These opinions are not necessarily those of my employer *** >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel