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: Tue, 12 Jun 2007 08:55:16 +0100
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Tue, 12 Jun 2007 00:51:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D936D925018D154694D8A362EEB0892001A2AC91@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: AceqLrHw9k0eE1VGTGivJ8LlKk1LqAATmB7NACi6M1AACIGnVgBdoppgAAOdz7E=
Thread-topic: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview
User-agent: Microsoft-Entourage/11.3.3.061214
On 12/6/07 08:03, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:

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

I'll probably get around to it eventually. ;-)

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

It's in the tree already.

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

My problem is: who are we to be selecting new reserved values? It seems kind
of risky! At least if you have some more reliable sboot detection method
apart from the e820 map, that could then indicate that the new type values
definitely have their guaranteed sboot meaning. If all you're keying off is
the e820 map, you're at risk of misinterpreting any crap that any random
bios flings at you on a non-sboot system.

 -- Keir



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