[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
- To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>, <xense-devel@xxxxxxxxxxxxxxxxxxx>
- 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
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- 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.
> 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
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
> since we obviously don't want two sets of changes for the same overall
> 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