Cihula, Joseph
2007-Aug-29 00:26 UTC
[Xen-devel] [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
Jan Beulich
2007-Aug-29 08:09 UTC
Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
>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
Keir Fraser
2007-Aug-29 10:13 UTC
Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
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
Keir Fraser
2007-Aug-29 16:56 UTC
Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
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
Cihula, Joseph
2007-Aug-29 21:52 UTC
RE: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
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 isnot to> be seen. But I don''t think it changes the fact that the easiest way tosolve> this particular problem in full is to extend the multiboot information > format. Sboot can then take full advantage of the extension, and thee820> hack goes away, while kexec can at least use it to avoid needingmanual> specification of no-real-mode, and can pass at least what usefulinformation it is> able to gather. > > -- KeirJust 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
Jan Beulich
2007-Aug-30 07:45 UTC
RE: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
>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
Keir Fraser
2007-Aug-30 09:47 UTC
Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview
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