RE: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

Keir Fraser <mailto:Keir.Fraser@xxxxxxxxxxxx> scribbled on Wednesday,
August 29, 2007 9:56 AM:
> On 29/8/07 11:13, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
> 
>> Indeed, and this also needs solving for kexec of Xen, too: it is
>> unsafe to drop back into real mode with interrupts enabled when
>> chain booted. This problem is sidestepped for Linux because kexec
>> simply strips off Linux's real-mode loader and sets up the
>> boot-sector information as if the real-mode section had run. But
>> actually no real-mode execution happens. 
> 
> Actually I see that kexec doesn't really pass much real information
> to the loaded kernel. It fakes out video info and EDID/EDD stuff is
not to
> be seen. But I don't think it changes the fact that the easiest way to
solve
> this particular problem in full is to extend the multiboot information
> format. Sboot can then take full advantage of the extension, and the
e820
> hack goes away, while kexec can at least use it to avoid needing
manual
> specification of no-real-mode, and can pass at least what useful
information it is
> able to gather.
> 
>  -- Keir

Just some background on sboot's current approach:
o  The new patch doesn't misuse, IMHO, the ACPI memory types.  By using
a type that is intended to indicate memory that is not usable by the
system, it allows kernels/VMMs that are not aware of sboot to still
treat these memory regions properly.
o  Once we have performed a TXT measured launch, we do not want to go
back and execute any unmeasured code.  So going back into BIOS (and
really not necessarily BIOS, but whatever later code may have set
vectors in the real mode IDT) breaks the trust of the TCB.
o  We do several checks in sboot to ensure that the e820 memory map does
not contain usable regions that overlap certain system-reserved areas
(SMM, MMIO, etc.), that the areas used by TXT and sboot are not marked
as usable, initial DMA protection covers all of RAM, etc.  So it is
important that Xen use the same table that sboot has used, verified, and
adjusted.
o  While the initial target for sboot is to launch Xen, we would like it
to be generic enough that it could be used by other VMMs or OS kernels,
e.g. Linux.  So we've tried to minimize the necessary post-sboot code
changes and altering the e820 table seems like a pretty generic way to
do that.  Now if all modern kernels/VMMs ignore GRUB's table and go back
to BIOS to read it (and can't have that disabled like Xen can) then this
approach won't be useful even if it is generic.

All that said, if extending the multiboot data can satisfy these
objectives then I'd be happy to discuss it.

Joe

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