It's a very interesting attack you mention. However, it doesn't seem to be restricted to virtualization or even trusted computing. The consequence is that if an untrusted program was ever in the past allowed to execute on the computer with direct access to the hardware, it could insert a threat that will persist even across reboots. Furthermore, the change may not be detectable by any antivirus program and will not be reflected in the PCR's of either the static or dynamic root of trust. This might already be happening today...
I think in practice this means that external hardware can never be allowed to do to/from memory areas containing (unencrypted) secrets, and I also think this was the original idea behind TXT. But as far as I can see, these types of attack means that it is difficult to by with current graphics hardware for even "a poor man's trusted graphics" - how can you trust a graphics card that could be running any firmware? For special applications you might be able to say to a customer "Only use  hardware from this list of trusted hardware that will only accept signed firmware updates etc. - open the computer casing and verify that all your hardware is on this list" which would be easy in the sense that it wouldn't require the definition of new standards etc. However, for the general consumer it might not seem so elegant.
Here it seems the way to go is for the graphics card to have endorsement keys/certificates. From there, there would be two routes to go: Either you need a mechanism in the chipset that can enforce something like "This DMA buffer can be accessed only by the CPU and device X on the PCI Express bus". I don't know enough about PCI Express / chipsets to say if it would be possible to enforce such a policy. Or you need a mechanism for negotiating an encryption key with the graphics card. All DMA buffers could then be end-to-end encrypted & MAC'en (using GCM or something similar) and the buffers could thus be freely exposed to all hardware. This might also guard against other kinds of hardware-based attacks (bus snooping etc.).
When you have that the next step is to define the mechanism that would make it possible for trusted and untrusted software to share the same screen.
Best regards,
Martin Thiim
On 7/18/08, Hal Finney <hal.finney@gmail.com> wrote:
Here's an article about the new laptops coming out with TXT support:


The only ones explicitly mentioning trusted platform support are the
Acer TravelMate 6493 and the Toshiba Tecra M10 and A10 models. However
it's possible that some of the others will as well - from what Joseph
said, I guess you can just look for the vPro keyword.

One other point Mike, I assume you are aware of Intel's page which has
the latest information on TXT:


This has the latest spec, which goes into a lot more detail than the
book, but basically will show the differences between what was planned
and what is currently implemented. I agree that it would be nice to
know about future directions and plans as well.

As far as VT-d, the DMA virtualization technology, I would still be
worried about the attack described here:


Apparently it is easy to overwrite firmware on certain peripheral
cards, allowing malicious software running in a VM to inject malware
into the card. Then when a different VM is running, and VT-d is
programmed to allow DMA into that VM's addressing space, the malware
can activate and steal or overwrite data that was supposed to be
protected against the 1st VM. Unless we can identify and limit access
to all peripheral cards with reprogrammable firmware, it is going to
be very hard to defend against this kind of attack.

Hal Finney

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
tboot-devel mailing list