[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |