Xen devel - Jun 2007 - [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

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

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 cpu
online/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 module
also,
> since we obviously don''t want two sets of changes for the same
overall
purpose.

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

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

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 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?
>> 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 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?
> 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

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

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

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

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

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

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

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

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

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