Re: [tboot-devel] Attack on tboot/TXT to be revealed

[Karthik . <tr...@gm...>]

Hi Joe

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

>>> Joe