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 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@in...>
> > This has been on my todo list for a while now but I haven't gotten to it yet (it
> covered in the MLE Developers Manual, however). Now that I just finished a few
> one more to come that requires Xen support), I should be able to knock this out pretty
> 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
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),
2. Ensure Xen fails secure. This would include things like the 'iommu=required' and 'ats'
command line parameters that we had added.