Xen devel - Oct 2007 - [Xense-devel] [PATCH] Intel(R) Trusted Execution Technology support

Attached is a 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 adds new functionality and re-structuring to
the previous version (which was posted in Aug.).

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
o  Verification and enforcement of launched environment

For more information, see http://www.intel.com/technology/security/.
This site also has a link to the Intel(R) TXT Preliminary Architecture
Specification, which has been updated for the new released platforms.


Patch Overview:
--------------
The bulk of the TXT code is now hosted at its own SourceForge site,
http://sourceforge.net/projects/tboot.  This project hosts the code in a
mercurial repo at http://tboot.sourceforge.net/hg/tboot.hg and contains
tarballs of the source.  This site is still very new, so please forgive
its incompleteness.  Questions on just tboot should be sent to
tboot-devel@lists.sourceforge.net or posted to the tboot project forum.

This patch is now only the Xen changes necessary to integrate with
tboot.  The top-level Makefile will ''wget'' the tboot source
tarball from
SourceForge, untar it, and then build.  Per feedback on the previous
patch, the changes are no longer built conditionally (but the code is
only executed if a measured launch was performed).  This patch applies
cleanly against c/s 16157:b28ae5f00553.

In addition to this re-structuring, the following additional
functionality has been added:
o  Support for S3/S4/S5
o  Verified Launch.  Tboot will extend verification from the MLE
(itself, as verified by TXT LCP) to the Xen and dom0, using policies
similar to the LCP and also stored in TPM NV.  These policies can be
created and managed by the tb_polgen tool and provisioned into TPM NV
using the lcptools.

There is more information about the functionality within the tboot/docs
files as well as configuration information and policy instructions.  The
documentation will be improved and flushed out over time so please
excuse its current spartan form.


Instructions for Use:
---------------------
o  The new tboot module must be added as the ''kernel'' in the
grub.conf
file.  The existing ''kernel'' entry should follow as a
''module''.  The
SINIT AC module (available with systems that support TXT) 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
           root (hd0,1)
           kernel /tboot.gz
           module /xen.gz no-real-mode 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 /BRLK_SINIT_20070910_release.BIN

o  Xen''s command line must include the ''no-real-mode''
option to prevent
Xen from reading the e820 table from BIOS.  The TXT code makes
modifications to the table passed via GRUB that the Xen portions of the
code need.

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 "TBOOT:".  Though tboot does initialize the COM port, it
is
best if this is also done by GRUB - grub.conf should have:
       serial --speed=115200 --unit=0
       terminal console serial


_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

On 27/10/07 02:56, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
> o  Xen''s command line must include the
''no-real-mode'' option to prevent
> Xen from reading the e820 table from BIOS.  The TXT code makes
> modifications to the table passed via GRUB that the Xen portions of the
> code need.
If that''s the only reason, we could add another command-line option, or
a
multiboot info flag, to prevent just the e820 part of real-mode execution.
Then you could still set video mode and get disc EDD info even when running
on tboot.

 -- Keir



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

On Saturday, October 27, 2007 1:15 AM, Keir Fraser
wrote:
> On 27/10/07 02:56, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>> o  Xen''s command line must include the
''no-real-mode'' option to
prevent
>> Xen from reading the e820 table from BIOS.  The TXT code makes
>> modifications to the table passed via GRUB that the Xen portions of
the
>> code need.
> 
> If that''s the only reason, we could add another command-line
option,
or a
> multiboot info flag, to prevent just the e820 part of real-mode
execution.
> Then you could still set video mode and get disc EDD info even when
running
> on tboot.
It isn''t the only reason:  the current tboot code will measure and
verify xen and dom0; if we let xen call into BIOS then we will be
transferring control to code that has not been verified.

If it is very important to initialize the video and disc from BIOS, we
could copy that code into tboot and execute it before tboot launches the
measured environment.  Is this necessary on current model systems (since
TXT is only available on Intel Core 2 -based systems)?

Joe

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

On 27/10/07 20:39, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
>> If that''s the only reason, we could add another command-line
option,
> or a
>> multiboot info flag, to prevent just the e820 part of real-mode
> execution.
>> Then you could still set video mode and get disc EDD info even when
> running
>> on tboot.
> 
> It isn''t the only reason:  the current tboot code will measure and
> verify xen and dom0; if we let xen call into BIOS then we will be
> transferring control to code that has not been verified.
> 
> If it is very important to initialize the video and disc from BIOS, we
> could copy that code into tboot and execute it before tboot launches the
> measured environment.  Is this necessary on current model systems (since
> TXT is only available on Intel Core 2 -based systems)?
It''d be nice to have, but it''s not essential.

 -- Keir



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

On 27/10/07 01:56, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
> Attached is a 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).
Seems to be missing asm-x86/tboot.h.

 -- Keir



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

On Monday, October 29, 2007 2:30 AM, Keir Fraser wrote:
> On 27/10/07 01:56, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>> Attached is a 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).
> 
> Seems to be missing asm-x86/tboot.h.
The build for tboot/tboot copies this file from tboot/include to
xen/include/asm-x86.  Do you prefer that it get checked in to Xen''s
repo
instead?
> 
>  -- Keir
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

On 29/10/07 15:38, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
>> Seems to be missing asm-x86/tboot.h.
> 
> The build for tboot/tboot copies this file from tboot/include to
> xen/include/asm-x86.  Do you prefer that it get checked in to
Xen''s repo
> instead?
Oh, yes I do. It is supposed to be a stable interface so this should be
okay.

I''m not taking the Makefile changes at this point anyway. We
don''t wget and
build any other bootloader components as part of the Xen build.

 -- Keir



_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

On Monday, October 29, 2007 8:49 AM, Keir Fraser wrote:
> On 29/10/07 15:38, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>>> Seems to be missing asm-x86/tboot.h.
>> 
>> The build for tboot/tboot copies this file from tboot/include to
>> xen/include/asm-x86.  Do you prefer that it get checked in to
Xen''s
repo
>> instead?
> 
> Oh, yes I do. It is supposed to be a stable interface so this should
be
> okay.
I''ll send a patch for this.
> 
> I''m not taking the Makefile changes at this point anyway. We
don''t
wget and
> build any other bootloader components as part of the Xen build.
Would you prefer it to be checked out with mercurial or just left as an
exercise for the user to download and build on his own?
> 
>  -- Keir
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

On 29/10/07 16:53, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
>> I''m not taking the Makefile changes at this point anyway. We
don''t
> wget and
>> build any other bootloader components as part of the Xen build.
> 
> Would you prefer it to be checked out with mercurial or just left as an
> exercise for the user to download and build on his own?
I''d take some documentation, perhaps even in the top-level README.
Perhaps
also an optional, self-contained build target?

I grabbed tboot.h for myself, by the way.

 -- Keir



_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

On Monday, October 29, 2007 9:57 AM, Keir Fraser wrote:
> On 29/10/07 16:53, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>>> I''m not taking the Makefile changes at this point anyway.
We don''t
wget and
>>> build any other bootloader components as part of the Xen build.
>> 
>> Would you prefer it to be checked out with mercurial or just left as
an
>> exercise for the user to download and build on his own?
> 
> I''d take some documentation, perhaps even in the top-level README.
No problem.
> Perhaps also an optional, self-contained build target?
I''ll disconnect the tboot pieces in my patched Makefile from the
top-level targets.
> 
> I grabbed tboot.h for myself, by the way.
> 
>  -- Keir
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

On 29/10/07 15:38, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
>>> Attached is a 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).
>> 
>> Seems to be missing asm-x86/tboot.h.
> 
> The build for tboot/tboot copies this file from tboot/include to
> xen/include/asm-x86.  Do you prefer that it get checked in to
Xen''s repo
> instead?
Okay, another issue. You can''t probe for tboot by mapping and reading
every
E820_RESERVED region (which is what the code you add to x86/setup.c does).
You don''t know what mmio regions you could be conflicting with by
making a
cacheable mapping and issuing memory reads (which can have side effects when
issued to I/O devices).

Why is the memory region not marked as E820_UNUSABLE by tboot? And/or extend
the multiboot info structure and transmit the address of the shared page
that way.

 -- Keir



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

On Monday, October 29, 2007 10:17 AM, Keir Fraser wrote:
> On 29/10/07 15:38, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>>>> Attached is a 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).
>>> 
>>> Seems to be missing asm-x86/tboot.h.
>> 
>> The build for tboot/tboot copies this file from tboot/include to
>> xen/include/asm-x86.  Do you prefer that it get checked in to
Xen''s
repo
>> instead?
> 
> Okay, another issue. You can''t probe for tboot by mapping and
reading
every
> E820_RESERVED region (which is what the code you add to x86/setup.c
does).
> You don''t know what mmio regions you could be conflicting with by
making a
> cacheable mapping and issuing memory reads (which can have side
effects when
> issued to I/O devices).
> 
> Why is the memory region not marked as E820_UNUSABLE by tboot? And/or
extend
> the multiboot info structure and transmit the address of the shared
page
> that way.
I didn''t mark it as UNUSABLE because dom0 doesn''t like low
memory that
it can''t probe and I didn''t realize that there would be a
problem with
marking it RESERVED.  However, I can mark it as UNUSABLE and then when I
find it, change it to RESERVED.  I''ll send a patch for this as well.
> 
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/10/07 17:41, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
>> Why is the memory region not marked as E820_UNUSABLE by tboot? And/or
> extend
>> the multiboot info structure and transmit the address of the shared
> page
>> that way.
> 
> I didn''t mark it as UNUSABLE because dom0 doesn''t like
low memory that
> it can''t probe and I didn''t realize that there would be a
problem with
> marking it RESERVED.  However, I can mark it as UNUSABLE and then when I
> find it, change it to RESERVED.  I''ll send a patch for this as
well.
By low memory, do you mean the signature is in the bottom megabyte of
memory? If that''s guaranteed then can we just scan the whole lot
0x00000-0xfffff (excluding VGA hole)?

 -- Keir



_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

On 29/10/07 17:52, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>
wrote:
>> I didn''t mark it as UNUSABLE because dom0 doesn''t
like low memory that
>> it can''t probe and I didn''t realize that there would
be a problem with
>> marking it RESERVED.  However, I can mark it as UNUSABLE and then when
I
>> find it, change it to RESERVED.  I''ll send a patch for this as
well.
> 
> By low memory, do you mean the signature is in the bottom megabyte of
memory?
> If that''s guaranteed then can we just scan the whole lot
0x00000-0xfffff
> (excluding VGA hole)?
Something like:
 for (p = 0; p < 0xa0000; p += PAGE_SIZE)
    check for sig at <p>;
 for (p = 0xe0000; p < 0x100000; p += PAGE_SIZE)
    check for sig at <p>;

??

 -- Keir



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

On Monday, October 29, 2007 10:52 AM, Keir Fraser wrote:
> On 29/10/07 17:41, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>>> Why is the memory region not marked as E820_UNUSABLE by tboot?
And/or extend
>>> the multiboot info structure and transmit the address of the shared
page
>>> that way.
>> 
>> I didn''t mark it as UNUSABLE because dom0 doesn''t
like low memory
that
>> it can''t probe and I didn''t realize that there would
be a problem
with
>> marking it RESERVED.  However, I can mark it as UNUSABLE and then
when I
>> find it, change it to RESERVED.  I''ll send a patch for this as
well.
> 
> By low memory, do you mean the signature is in the bottom megabyte of
> memory? If that''s guaranteed then can we just scan the whole lot
> 0x00000-0xfffff (excluding VGA hole)?
Yes, it''s in the lower 1MB and that is where dom0 has problems with
gaps.  But I think that the UNUSABLE->RESERVED approach will be just as
effective and reduce the amount of memory to scan as well.

Joe

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

On 29/10/07 18:00, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
>> By low memory, do you mean the signature is in the bottom megabyte of
>> memory? If that''s guaranteed then can we just scan the whole
lot
>> 0x00000-0xfffff (excluding VGA hole)?
> 
> Yes, it''s in the lower 1MB and that is where dom0 has problems
with
> gaps.  But I think that the UNUSABLE->RESERVED approach will be just as
> effective and reduce the amount of memory to scan as well.
Okay, we should limit the scan to page-aligned addresses in UNUSABLE regions
below 1MB. It makes sense to put the UNUSABLE->RESERVED hack in Xen itself,
rather than in tboot. Once the interface is baked into 3.2.0 it''s not
changing on our side.

 -- Keir



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

On Monday, October 29, 2007 11:05 AM, Keir Fraser wrote:
> On 29/10/07 18:00, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>>> By low memory, do you mean the signature is in the bottom megabyte
of
>>> memory? If that''s guaranteed then can we just scan the
whole lot
>>> 0x00000-0xfffff (excluding VGA hole)?
>> 
>> Yes, it''s in the lower 1MB and that is where dom0 has problems
with
>> gaps.  But I think that the UNUSABLE->RESERVED approach will be just
as
>> effective and reduce the amount of memory to scan as well.
> 
> Okay, we should limit the scan to page-aligned addresses in UNUSABLE
regions
> below 1MB. It makes sense to put the UNUSABLE->RESERVED hack in Xen
itself,
> rather than in tboot. Once the interface is baked into 3.2.0 it''s
not
> changing on our side.
I''d like to allow for the shared page to be moved to a higher memory
location in the future, so I''d prefer not to limit the search to below
1MB.  Since only tboot is using the UNUSABLE type and it should find the
shared page in the first UNUSABLE section anyway (whether it gets moved
or not), the search should still be quick.  Also, I''ll only change the
type from UNUSABLE->RESERVED if it is found in the lower 1MB.

Joe

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

On 29/10/07 18:34, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
>> Okay, we should limit the scan to page-aligned addresses in UNUSABLE
> regions
>> below 1MB. It makes sense to put the UNUSABLE->RESERVED hack in Xen
> itself,
>> rather than in tboot. Once the interface is baked into 3.2.0
it''s not
>> changing on our side.
> 
> I''d like to allow for the shared page to be moved to a higher
memory
> location in the future, so I''d prefer not to limit the search to
below
> 1MB.  Since only tboot is using the UNUSABLE type and it should find the
> shared page in the first UNUSABLE section anyway (whether it gets moved
> or not), the search should still be quick.  Also, I''ll only change
the
> type from UNUSABLE->RESERVED if it is found in the lower 1MB.
Actually I have a better idea to avoid the scan entirely. tboot should
append ''tboot=<address of shared area>'' to
Xen''s command line (e.g.,
tboot=0x71000). This gives a better more guaranteed handoff from tboot to
Xen, it avoids the user needing to manually add any options to Xen''s
command
line (we can make tboot= imply no-real-mode), and means that rather than
doing a scan we simply need to confirm the UUID is at the given address.

I can easily do the Xen side of this if you agree it makes sense.

 -- Keir



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

On Monday, October 29, 2007 11:47 AM, Keir Fraser wrote:
> On 29/10/07 18:34, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
>>> Okay, we should limit the scan to page-aligned addresses in
UNUSABLE
regions
>>> below 1MB. It makes sense to put the UNUSABLE->RESERVED hack in
Xen
itself,
>>> rather than in tboot. Once the interface is baked into 3.2.0
it''s
not
>>> changing on our side.
>> 
>> I''d like to allow for the shared page to be moved to a higher
memory
>> location in the future, so I''d prefer not to limit the search
to
below
>> 1MB.  Since only tboot is using the UNUSABLE type and it should find
the
>> shared page in the first UNUSABLE section anyway (whether it gets
moved
>> or not), the search should still be quick.  Also, I''ll only
change
the
>> type from UNUSABLE->RESERVED if it is found in the lower 1MB.
> 
> Actually I have a better idea to avoid the scan entirely. tboot should
> append ''tboot=<address of shared area>'' to
Xen''s command line (e.g.,
> tboot=0x71000). This gives a better more guaranteed handoff from tboot
to
> Xen, it avoids the user needing to manually add any options to
Xen''s
command
> line (we can make tboot= imply no-real-mode), and means that rather
than
> doing a scan we simply need to confirm the UUID is at the given
address.
> 
> I can easily do the Xen side of this if you agree it makes sense.
Sounds good.  I''ll work up a patch for tboot and post a new tarball
tonight.

Joe

_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

Attached is a patch with a new Makefile (diff''ed from vanilla Xen) that
creates optional targets for tboot and uses the newly-posted release
(20071029) from SF.  I have also added some text at the end of the
README file to describe Intel(R) TXT and tboot and how to build them
using the targets.

The new tboot release implements the ''tboot=0x1234'' command
line
interface described below for passing the physical address of the tboot
shared page to Xen.  It includes a few other cleanups as well, as can be
seen in the changelog.

Joe

On Monday, October 29, 2007 12:27 PM, Cihula, Joseph
wrote:
> On Monday, October 29, 2007 11:47 AM, Keir Fraser wrote:
>> On 29/10/07 18:34, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
>> 
>>>> Okay, we should limit the scan to page-aligned addresses in
UNUSABLE
>>>> regions below 1MB. It makes sense to put the
UNUSABLE->RESERVED
hack in
>>>> Xen itself, rather than in tboot. Once the interface is baked
into
3.2.0
>>>> it''s not changing on our side.
>>> 
>>> I''d like to allow for the shared page to be moved to a
higher memory
>>> location in the future, so I''d prefer not to limit the
search to
below
>>> 1MB.  Since only tboot is using the UNUSABLE type and it should
find
the
>>> shared page in the first UNUSABLE section anyway (whether it gets
moved
>>> or not), the search should still be quick.  Also, I''ll
only change
the
>>> type from UNUSABLE->RESERVED if it is found in the lower 1MB.
>> 
>> Actually I have a better idea to avoid the scan entirely. tboot
should
>> append ''tboot=<address of shared area>'' to
Xen''s command line (e.g.,
>> tboot=0x71000). This gives a better more guaranteed handoff from
tboot to
>> Xen, it avoids the user needing to manually add any options to
Xen''s
command
>> line (we can make tboot= imply no-real-mode), and means that rather
than
>> doing a scan we simply need to confirm the UUID is at the given
address.
>> 
>> I can easily do the Xen side of this if you agree it makes sense.
> 
> Sounds good.  I''ll work up a patch for tboot and post a new
tarball
> tonight.
> 
> Joe
> 
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@lists.xensource.com
> http://lists.xensource.com/xense-devel

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