| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support
|
To: |
"Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>, <xense-devel@xxxxxxxxxxxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support |
|
From: |
"Cihula, Joseph" <joseph.cihula@xxxxxxxxx> |
|
Date: |
Sat, 27 Oct 2007 13:39:15 -0700 |
|
Cc: |
"Xu, James" <james.xu@xxxxxxxxx>, "Wang, Shane" <shane.wang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx> |
|
Delivery-date: |
Sat, 27 Oct 2007 13:40:33 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<C348B217.F90F%Keir.Fraser@xxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<D936D925018D154694D8A362EEB0892002C3A1B8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C348B217.F90F%Keir.Fraser@xxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
AcgYPKeHAh+s/rrjQ0OzxTZHSH6adQANNIIDABnLhfA= |
|
Thread-topic: |
[Xen-devel] [PATCH] Intel(R) Trusted Execution Technology support |
On Saturday, October 27, 2007 1:15 AM, Keir Fraser wrote:
> On 27/10/07 02:56, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home