>From an interview with Joanna (http://www.infoworld.com/article/09/01/06/Researchers_hack_into_Intels_vPro_1.html):
The 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, Rutkowska said.
As for specifics of how the attack relates to TXT, you will need to see the presentation.
From: Karthik . [mailto:tresko1@...]
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@....>..]
> Sent: Wednesday, January 07, 2009 2:49 PM
> >> From: Hal Finney [mailto:hal.finney@....>..]
> >> Sent: Tuesday, January 06, 2009 7:26 PM
> >> There is one aspect of tboot security which I always wondered about.
> >> Maybe someone could reassure me that it is OK.
> >> Shouldn't the MLE check to see that the page tables are/were set up
> >> correctly?
> On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <joseph.cihula@......> wrote:
> > 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 implications:
>>> 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 reviewed.
>>> 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 being reviewed.
>>> 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.