From an interview with Joanna (http://www.infoworld.com/article/09/01/06/Researchers_hack_into_Intels_vPro_1.html):
researchers conducted their attack against a program called tboot, used to load
trusted versions of Linux or virtual machine modules onto the computer. They
chose tboot because it is one of the few programs available that takes
advantage of the TXT technology, but they did not find bugs in tboot itself,
As for specifics of how the attack relates to TXT, you will need
to see the presentation.
From: Karthik .
Sent: Monday, February 02, 2009 9:08 AM
Subject: Re: [tboot-devel] Attack on tboot/TXT to be revealed
I am confused as to whether this attack is on the Tboot code or is it on the
TXT architecture. Can you please clarify?
> From: Hal Finney [mailto:hal.finney@gm...]
> Sent: Wednesday, January 07, 2009 2:49 PM
> >> From: Hal Finney [mailto:hal.finney@gm...]
> >> Sent: Tuesday, January 06, 2009 7:26 PM
> >> There is one aspect of tboot security which I always wondered
> >> Maybe someone could reassure me that it is OK.
> >> Shouldn't the MLE check to see that the page tables are/were set
> >> correctly?
> On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph
> > This has been on my todo list for a while now but I haven't gotten to
it yet (it *is*
> covered in the MLE Developers Manual, however). Now that I just finished a
few patches (and
> one more to come that requires Xen support), I should be able to knock
this out pretty soon.
> I would like to see a document which lists known security flaws like
> this in tboot. It might help to reduce claims that "Intel TXT is
> broken" and the like. Do you know of other security loopholes which
> are planned for closure in future versions?
>>> I'll work on creating a TODO list for tboot, which will include
the implications/impact of the items and also will include functional tasks.
>>> These are the TODO items that I know of that have security
>>> 1. Verification of post-launch physical memory layout (see above).
A patch is ready and being reviewed.
>>> 2. VT-d protections extended to all of usable memory. The current
tboot setting for VT-d (PMR) DMA protection is just the tboot address range,
which leaves out Xen, dom0, >>> etc. as well as where they are
relocated to before Xen enables VT-d DMA remapping. A patch is ready and being
>>> 3. S3 memory integrity protection. The non-tboot TCB (and possibly
more) needs to have its integrity measured before entering S3 and verified on
resume. For Xen, this would >>> be the hypervisor and that would be
responsible for doing this for domains (including dom0). A patch is ready and
>>> 4. Validation of Sx addresses. We are adding GAS (generic address
structure) support to tboot's Sx code. GAS allows for non-port -based Sx
triggering (i.e. memory writes). >>> This allows for the possibility
that malicious ACPI code (or tampered with before tboot) could reference
addresses within Xen or tboot and cause overwrites when a sleep state
>>> is entered. So the addresses should be checked against
tboot/Xen/domain addr ranges before being used. This is part of the GAS support
patch, which is ready and being >>> reviewed.
>>> 5. Run tboot code through a static analysis checker.
>>> 6. Perform a thorough tboot code and design review on latest code.
>>> There are also some things that are not directly related to tboot,
but are really only relevant if tboot is being used:
>>> 1. Review all Xen code for pre-launch dependencies. This would be
things like the GAS issue mentioned above, BIOS calls (which should all be
disabled when invoked by >>> tboot), etc.
>>> 2. Ensure Xen fails secure. This would include things like the
'iommu=required' and 'ats' command line parameters that we had added.