Xen devel - Aug 2007 - [RFC][PATCH][0/4] Intel(R) Trusted Execution Technology support: Overview

Attached is a preliminary patch that adds Intel(R) Trusted Execution
Technology (Intel(R) TXT) support to Xen.  Intel(R) TXT was formerly
known by the codename LaGrande Technology (LT).

This version of the patch adds new functionality and support to the
previous version (which was posted two months ago).  It continues to
support the Intel(R) TXT Technology Enabling Platform (TEP) and also
adds support for the newly launched vPro and Intel(R) Q35 Express
chipset -based systems.

Intel(R) TXT in Brief:
----------------------
o  Provides dynamic root of trust for measurement (DRTM)
o  DMA protection (on SDV3/TEP platforms only)
o  Data protection in case of improper shutdown
o  Verification and enforcement of launched environment

For more information, see http://www.intel.com/technology/security/. 
This site also has a link to the Intel(R) TXT Preliminary Architecture
Specification, which has been updated for the new released platforms.


Overview of Patch Functionality:
--------------------------------
o  Measured Launch.  If the processor is detected as being TXT-capable
and enabled then the code will attempt to perform a measured launch.  If
the measured launch process fails (processor is not capable, TXT is not
enabled, missing SINIT, corrupted data, etc.)) then it will fall-through
to a non-TXT boot of Xen.

o  Teardown of measured environment.  When Xen exits the measured
environment will be torn down properly.  This does not currently support
all exit modes (e.g. shutdown via dom0).

o  Reset data protection.  Intel(R) TXT hardware prevents access to
secrets if the system is reset without clearing them from memory (as
part of a TXT teardown).  This code will support this by setting the
flag indicating that memory should be so protected during the measured
launch and clearing the flag just before teardown.

o  Protection of TXT memory ranges.  Intel(R) TXT reserves certain
regions of RAM for its use and also defines several MMIO regions.  These
regions (excluding the TXT public configuration space) are protected
from use by any domains (including dom0).

o  Intel(R) TXT Launch Control Policy (LCP) tools.  The
sboot/tools/lcptools project contains a set of tools (and basic
documentation) that can be used to create and provision TXT Launch
Control policies.  LCP uses TPM non-volatile storage (TPM NV) to hold a
launch policy, which the SINIT AC module reads and uses to enforce which
measured launched environments (MLEs) (e.g. sboot) can be launched
(based on a SHA-1 hash).  TXT LCP will be documented in a separate
specification to be released shortly.  These tools require a TPM
Software Stack (TSS) that supports the Tspi_NV_* API.  The tip of the
CVS TrouSerS project supports them but the bundled code does not.  This
patch set also include a version of TrouSerS (near the tip) that
supports them.


Patch Contents:
---------------
txt-xen-0828_01-xen.patch - the changes to Xen for Intel(R) TXT support
txt-xen-0608_02_{a,b,c,d}-sboot.patch - the new sboot module that
performs the measured launch (broken into 4 by ''split'')
txt-xen-0608_03-sboot-tools.patch - tools for LCP and testing
txt-xen-0608_04-trousers - a version of TrouSerS that supports Tspi_NV_*
API (this is a big attachment and I''m not going to split it, so it may
take a while to get through the mail server)

Instructions for Use:
---------------------
o  By default, the functionality is disabled in the build.  It can be
enabled by changing the INTEL_TXT flag to ''y'' in Config.mk.

o  The new sboot module must be added as the ''kernel'' and xen
made a
''module''.  The SINIT AC module (available with systems that
support TXT)
must be added to the grub.conf boot config as the last module, e.g.:
	title Xen 3.1.0 w/ Intel(R) Trusted Execution Technology
		kernel /sboot.gz
		module /xen.gz no-real-mode dom0_mem=524288
com1=115200,8n1
		module /vmlinuz-2.6.18-xen root=/dev/VolGroup00/LogVol00
ro
		module /initrd-2.6.18-xen.img
		module /lpg_sinit_20050831_pae.auth.bin

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.

o  Progress of the launch process is indicated via debug printk''s to
COM1 (hardcoded).  These appear before the normal "(XEN)" output and
are
prefixed by "SBOOT:".  The code (in early_printk.c) does not
initialize
the COM port so this needs to be done by GRUB - grub.conf should have:
	serial --speed=115200 --unit=0
	terminal console serial


Interesting Items of Note:
--------------------------
o  A Xen that is not compiled for Intel(R) TXT can still be launched by
sboot, however it will not protect any of the TXT memory nor sboot
itself.  And it will hang on reboot/shutdown.

o  A Xen compiled for Intel(R) TXT can be used without sboot and will
simply detect that it was not launched in a measured environment and
behave as normal.

o  The patch no longer defines new E820 memory types.  It does, however,
add support to Xen for the E820_UNUSABLE type (5) defined in the latest
ACPI spec.  sboot will copy and alter the e820 table provided by GRUB to
"reserve" its own memory plus the TXT memory regions.  These are
marked
as E820_UNUSABLE so that the patched Xen code can prevent them from
being assigned to dom0.  The single page that sboot reserves for
communication (sharing) with Xen is marked as reserved and identified by
a UUID at its beginning.  The patched Xen code will look for this page
when parsing the e820 table and uses its presence as the indicator that
a measured launch took place (the e820 table is not altered if the
measured launch fails for any reason).

o  sboot is always built 32bit and runs in protected mode without PAE or
paging enabled.  sboot lives at (copies itself to) 0x70000.  While this
location works functionally, it cannot be protected from dom0 (causes a
fault).  We might be able to map a separate set of pages over this for
dom0, but that seems like a lot of work compared to just moving Xen (and
then sboot) up a bit.

o  Because a proper teardown requires turning off VMX on every
core/thread before executing GETSEC[SEXIT], some changes were made to
the Xen shutdown code.  An initial commonization of the reboot and
shutdown routines was done so that this new code would only have to be
put in one place.  Future patches will commonize the other routines in
Xen that shutdown or reboot the system, such that they will also perform
a teardown of the measured environment.  Because the
''shutdown'' command
in dom0 does not go through Xen''s shutdown routines, it will cause a
hang--''reboot'' works fine.  This will be addressed in a future
patch,
along with S3/S4 support.

o  The code requires that VT be enabled as well as TXT.  This is because
the mechanism for bringing up the APs uses VMX to create a mini-VM in
order to trap on INIT-SIPI-SIPI.

o  Currently only sboot is measured.  We plan to extend this to xen and
dom0 in the near future.

o  Support for the TEP''s NoDMA capability has been implemented in this
patch.  NoDMA has been superseded by VT-d and is used by default on the
new TXT platforms.  The VT_D define in sboot/include/config.h is for
when Xen supports VT-d.  At that time this code can be enabled and it
will DMA protect all of the memory until Xen has enabled VT-d
translation for the regions that it cares about.  But enabling it before
Xen has VT-d support will cause dom0 to fail to boot.

o  The sboot/tools/txt-test project is a Linux kernel module that reads
some of the TXT registers and also verifies the memory protections.  It
will also display the sboot boot log, in case a system does not have
serial support.

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

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

Jan


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

On 29/8/07 09:09, "Jan Beulich" <jbeulich@novell.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/8/07 11:13, "Keir Fraser" <keir@xensource.com> 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



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

Keir Fraser <mailto:Keir.Fraser@cl.cam.ac.uk> scribbled on Wednesday,
August 29, 2007 9:56 AM:
> On 29/8/07 11:13, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

>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.
Which makes sense. You just have to provide a means to obtain all the info
normally obtained from BIOS then.
>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.
I don''t think Linux has any plans on going multiboot. While (for
paravirt
support) there are now ways to bypass real mode code, it is still being
assumed that the information no longer collected that way will be provided
another way if the kernel is privileged (aka dom0 in Xen).

For the even more generic question of supporting arbitrary(?) OSes, I
wonder how you can make assumptions about these, namely their
intentions/needs to boot from and/or switch back to real mode. To me this
seems like a conceptual issue then.

Jan


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

On 29/8/07 22:52, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
> 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.
Oh, I see that this extra type is defined by ACPI 3. That makes it quite
reasonable to use then, assuming there are no mad BIOSes that abuse this new
type. I guess we should cross that bridge only if we come to it.

 -- Keir


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