WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>, <xense-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Sat, 9 Jun 2007 22:42:44 -0700
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Sat, 09 Jun 2007 22:40:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C29038E8.8B0F%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: <D936D925018D154694D8A362EEB08920019E08E1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C29038E8.8B0F%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceqLrHw9k0eE1VGTGivJ8LlKk1LqAATmB7NACi6M1A=
Thread-topic: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Keir Fraser <mailto:Keir.Fraser@xxxxxxxxxxxx> scribbled on Saturday,
June 09, 2007 3:01 AM:
> On 9/6/07 01:39, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel