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: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>, <xense-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sun, 10 Jun 2007 10:30:39 +0100
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Sun, 10 Jun 2007 02:26:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D936D925018D154694D8A362EEB08920019E0A08@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceqLrHw9k0eE1VGTGivJ8LlKk1LqAATmB7NACi6M1AACIGnVg==
Thread-topic: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
User-agent: Microsoft-Entourage/11.3.3.061214
On 10/6/07 06:42, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:

> 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:
>> 
> 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.

Xen could be moved to 2MB easily enough. But even Xen now has a permanent
real-mode mapping at 0x90000. We could protect it by copying the bottom
megabyte somewhere else in the physical address space, and translating
mapping requests into the copy. This would also protect the BIOS and other
stuff which may not get refreshed across a soft reboot.

> 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.

So the AP entry point in the shared page will go away?

> 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.

Another issue is that Xen now calls the BIOS to get the e820 map itself,
since GRUB was messing it up on some systems. Hence your modified e820 map
will, by default, be ignored.

Perhaps we could take a multiboot_info feature bit, or add an extra
multiboot module, to indicate sboot and to provide shared info?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel