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