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