Ok I found the TOC for the book and it looks very interesting. I'm wondering if it is Intel's / TCG's "vision" that trusted graphics can be realized with current hardware or if it is to make use of some to-be-announced graphics hardware of the future. Maybe this is clear from the book you mention.
If you take Intel's TXT, the MLE will have full control of the computing environment. Hence, it should be able to seize complete control of the graphics cards and also have control over what (if any) other software can access the display. It could simply chose to clear the display of secrets before returning to the "unsafe" mode. The user would be able to recognize the trusted mode based on shared secret arranged at a time when the user trusts the computer was indeed executing in the trusted mode. All this would be possible with today's hardware and would at least allow for a "poor man's trusted graphics."
However, this solution is hardly practical - people will want to have "trusted windows" running alongside the untrusted windows and non-trusted programs should still be able to run in the background (but not be able to interfere with the trusted windows). Can this be handled with current hardware? I'm not sure but maybe. The driver actually communicating with the hardware would have to execute in the trusted mode. It would have full responsibility for communicating with the graphics hardware. All painting etc. from untrusted applications would have to go through the trusted mode / trusted driver which can then take care of fitering the requests as approprate. So the question is if access to the graphics hardware can be blocked from the untrusted mode? The MLE could also act as a hypervisor and (assuming a late-launch scenario) move the running, untrusted operating system into a virtual machine and present it with a virtual graphics card or at least provide it with a graphics driver that would do the actual painting using hypervisor calls ending up in the trusted driver. At least theoretically the trusted driver would be able to completely control utilization of the graphics resources (including textures, z-plane etc.) but I don't know if it is feasible performance-wise. The framebuffer would have to be protected from DMA transfers - the TXT chipset registers could be used for this purpose. The biggest problem is that you need to have a trusted graphics driver and that as things are now will be hardware dependent.
On 7/16/08, Mike Hearn <email@example.com> wrote:
Only the book, sorry. If you google for "trusted graphics translation
table" you can see a few patents and presentations on it, but this is
all early days.
On Wed, Jul 16, 2008 at 1:38 PM, Martin Thiim <firstname.lastname@example.org> wrote:
> Interesting. However, as far as I can see it is not part of TXT. TXT is
> short for Trusted Execution Technology and all the documentation I've seen
> from Intel about TXT seems to concern itself with trusted execution with no
> mention of trusted I/O.
> You say there is a defined mechanism for trusted graphics, TGTT. However, I
> can't find anything on this via Google. Do you have any references?
> Martin Thiim
> On 7/16/08, Mike Hearn <email@example.com> wrote:
>> On Wed, Jul 16, 2008 at 8:43 AM, Martin Thiim <firstname.lastname@example.org> wrote:
>> > regarding the original posters mention of trusted graphics and input
>> > paths: Does anyone know what the status on this is? I know this is separate
>> > technology from TXT but certainly it is part of trusted computing.
>> The "safer computing initiative" book talks a bit about this but the
>> details are frustratingly absent. Essentially:
>> - Yes it's a part of TXT
>> - There is a defined mechanism for this (TGTT)
>> - The process is that the video card is given restricted access to
>> some section of a VMs memory space
>> - The video card composites the trusted surface with the untrusted
>> surface such that trusted surface is always top in the z-order
>> No mention was made of how this would interact with composited
>> desktops like Compiz, Aqua or Vista. I strongly suspect this
>> straightforward implementation will have to be scrapped or at least
>> augmented to allow for a VM to be bound to a secure OpenGL texture
>> that the main untrusted OS can then composite into the final image.
>> The trick being that the video card would have to somehow prevent the
>> main VM from reading back any section of the screen that had been
>> touched by the secure texture - including arbitrary transforms like
>> reflection using pixel shaders. Ugh. Sounds complicated.
>> I'll settle for a basic system that uses the technique described in
>> the book for now, but obviously for production desktop use if you want
>> to use a trusted graphics path then the issue of compositing will need
>> to be addressed.
>> The trusted channel to the keyboard seemed more fleshed out, there was
>> a long discussion of how to handle laptop keyboards (as they aren't
>> usb devices like on a desktop) although I don't remember the exact
>> details of how you authenticate that the keyboard is a real hardware
>> keyboard and not an emulation.