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: Tue, 12 Jun 2007 00:03:08 -0700
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Tue, 12 Jun 2007 00:01:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C291834F.8B50%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: <D936D925018D154694D8A362EEB08920019E0A08@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C291834F.8B50%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceqLrHw9k0eE1VGTGivJ8LlKk1LqAATmB7NACi6M1AACIGnVgBdoppg
Thread-topic: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
Keir Fraser <mailto:Keir.Fraser@xxxxxxxxxxxx> scribbled on Sunday, June
10, 2007 2:31 AM:
> 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.

In order to transition to real mode we will need to stay below 1M, so I
think your suggestion of copying it and translating to the copy will
turn out to be the best solution to the problem.  Plus, if the
trampoline code is used after initial boot then it really should be
protected from dom0 as well.  Will you be making this change?

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

Yes, the AP entry point would no longer be needed.

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

As Linux also reads the memory map directly, I expected that we would
end up having to modify BIOS's copy eventually.  Looks like perhaps
sooner than later.  When will this change go into the tree?

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

This would also work.  One advantage of the modified e820 table is that
I expect that most software that parses it will treat the new types as
reserved and so will not use the regions that it marks, even if that
software was not specifically modified to recognize the types.

> 
>  -- Keir

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