| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologys
|
To: |
"Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Joseph Cihula" <joseph.cihula@xxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview |
|
From: |
"Jan Beulich" <jbeulich@xxxxxxxxxx> |
|
Date: |
Thu, 30 Aug 2007 08:45:32 +0100 |
|
Cc: |
xen-devel@xxxxxxxxxxxxxxxxxxx, Edwin Zhai <edwin.zhai@xxxxxxxxx>, James Xu <james.xu@xxxxxxxxx>, Shane Wang <shane.wang@xxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx, Gang Wei <gang.wei@xxxxxxxxx> |
|
Delivery-date: |
Thu, 30 Aug 2007 00:44:55 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<D936D925018D154694D8A362EEB08920024A1B04@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
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: |
<C2FB053C.14FBB%keir@xxxxxxxxxxxxx> <C2FB63C2.15008%Keir.Fraser@xxxxxxxxxxxx> <D936D925018D154694D8A362EEB08920024A1B04@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
>o Once we have performed a TXT measured launch, we do not want to go
>back and execute any unmeasured code. So going back into BIOS (and
>really not necessarily BIOS, but whatever later code may have set
>vectors in the real mode IDT) breaks the trust of the TCB.
Which makes sense. You just have to provide a means to obtain all the info
normally obtained from BIOS then.
>o While the initial target for sboot is to launch Xen, we would like it
>to be generic enough that it could be used by other VMMs or OS kernels,
>e.g. Linux. So we've tried to minimize the necessary post-sboot code
>changes and altering the e820 table seems like a pretty generic way to
>do that. Now if all modern kernels/VMMs ignore GRUB's table and go back
>to BIOS to read it (and can't have that disabled like Xen can) then this
>approach won't be useful even if it is generic.
I don't think Linux has any plans on going multiboot. While (for paravirt
support) there are now ways to bypass real mode code, it is still being
assumed that the information no longer collected that way will be provided
another way if the kernel is privileged (aka dom0 in Xen).
For the even more generic question of supporting arbitrary(?) OSes, I
wonder how you can make assumptions about these, namely their
intentions/needs to boot from and/or switch back to real mode. To me this
seems like a conceptual issue then.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home