[PATCH] Intel(R) Trusted Execution Technology support

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
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
[hidden email] 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
[hidden email]
http://lists.xensource.com/xense-devel

txt-xen-1026.patch (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 27/10/07 02:56, "Cihula, Joseph" <[hidden email]> 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



_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
On Saturday, October 27, 2007 1:15 AM, Keir Fraser wrote:
> On 27/10/07 02:56, "Cihula, Joseph" <[hidden email]> 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

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 27/10/07 20:39, "Cihula, Joseph" <[hidden email]> 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



_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
In reply to this post by Cihula, Joseph
On 27/10/07 01:56, "Cihula, Joseph" <[hidden email]> 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



_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
On Monday, October 29, 2007 2:30 AM, Keir Fraser wrote:
> On 27/10/07 01:56, "Cihula, Joseph" <[hidden email]> 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 29/10/07 15:38, "Cihula, Joseph" <[hidden email]> 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
On Monday, October 29, 2007 8:49 AM, Keir Fraser wrote:
> On 29/10/07 15:38, "Cihula, Joseph" <[hidden email]> 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 29/10/07 16:53, "Cihula, Joseph" <[hidden email]> 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
On Monday, October 29, 2007 9:57 AM, Keir Fraser wrote:
> On 29/10/07 16:53, "Cihula, Joseph" <[hidden email]> 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
In reply to this post by Cihula, Joseph
On 29/10/07 15:38, "Cihula, Joseph" <[hidden email]> 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



_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
On Monday, October 29, 2007 10:17 AM, Keir Fraser wrote:
> On 29/10/07 15:38, "Cihula, Joseph" <[hidden email]> 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

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 29/10/07 17:41, "Cihula, Joseph" <[hidden email]> 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 29/10/07 17:52, "Keir Fraser" <[hidden email]> 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



_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
In reply to this post by Keir Fraser
On Monday, October 29, 2007 10:52 AM, Keir Fraser wrote:
> On 29/10/07 17:41, "Cihula, Joseph" <[hidden email]> 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

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 29/10/07 18:00, "Cihula, Joseph" <[hidden email]> 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



_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
On Monday, October 29, 2007 11:05 AM, Keir Fraser wrote:
> On 29/10/07 18:00, "Cihula, Joseph" <[hidden email]> 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

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Keir Fraser
On 29/10/07 18:34, "Cihula, Joseph" <[hidden email]> 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



_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support

Cihula, Joseph
On Monday, October 29, 2007 11:47 AM, Keir Fraser wrote:
> On 29/10/07 18:34, "Cihula, Joseph" <[hidden email]> 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: RE: [Xen-devel] [PATCH] Intel(R) Trusted ExecutionTechnology support

Cihula, Joseph
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" <[hidden email]> 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
> [hidden email]
> http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel

xen-txt-cmdline-change.patch (4K) Download Attachment