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

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel