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/
Home Products Support Community News


Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologys

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Joseph Cihula <joseph.cihula@xxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 29 Aug 2007 11:13:00 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Edwin Zhai <edwin.zhai@xxxxxxxxx>, James Xu <james.xu@xxxxxxxxx>, Shane Wang <shane.wang@xxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx, Gang Wei <gang.wei@xxxxxxxxx>
Delivery-date: Wed, 29 Aug 2007 03:13:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46D545C5.76E4.0078.0@xxxxxxxxxx>
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: AcfqJS1qa85J3FYYEdyVXAAX8io7RQ==
Thread-topic: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
User-agent: Microsoft-Entourage/
On 29/8/07 09:09, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> o  Xen's command line must include the 'no-real-mode' option to prevent
>> Xen from reading the e820 table from BIOS.  The TXT code makes
>> modifications to the table passed via GRUB that the Xen portions of the
>> code need.
> This doesn't sound like something that is only a temporary workaround.
> However, suppressing real mode execution has its own issues:
> - There are known issues with GrUB properly passing the E820 table, meaning
>   that Xen would use incorrect (truncated) memory information if it is
> prevented
>   from getting the information from the BIOS directly.
> - There is more than just the E820 information retrieved while in real mode,
>   and this information is known to be required in certain cases for proper
>   functioning of Dom0.
> So I think this needs to be addressed in some way.

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.

My suggestion for Xen is to provide an additional descriptor structure as
part of the multiboot information -- basically a sequence of (chunk_id,
chunk_length, chunk_data) tuples. This could contain a no-data chunk to
indicate real mode is off limits, followed by chunks with info about EDID,
EDD and video (multiboot already has a section for e820). Indeed, it could
also contain a chunk with all the necessary info about sboot, and this would
be *much* preferable to hijacking an e820 type, which I really think cannot

My only uncertainty is how to extend multiboot in this way. Either we could
take a feature flag and then tack the info structure on the end of the
existing multiboot structure, or we could make it e.g., the last multiboot
module and place a UUID (magic value) at the start of the module data.

The latter has advantage that we do not make unofficial changes to the
multiboot info structure. Also it may not be necessary to change the kexec
user-space tools, and instead pass the extra info module pre-constructed.

OTOH, Multiboot 1 is now pretty static (all the development is on Multiboot
2), and the code for constructing the info structure needs to exist
*somewhere* -- may as well be implemented as part of the existing kexec
toolset? And of course it doesn't really much matter either way for sboot,
as the code clearly gets added to sboot either way.

Thoughts? I'd be happy to help work out some more of the details.

 -- Keir

Xen-devel mailing list