Re: [tboot-devel] Buying a machine that will actually work with TXT

[Mike H. <mi...@pl...>]

On Wed, Jul 16, 2008 at 2:32 PM, Martin Thiim <ma...@th...> wrote:
> 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.

The book makes very little about concrete implementation clear
unfortunately. It does describe the late launch inter-cpu protocols in
detail but little else - it's very much a conceptual overview (it does
an ok job of that mind you).

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

Yes in theory. In practice that sounds rather hard. There's a lot of
state tied up in modern graphics drivers. The way I think it's
intended to work - at least if I understand TGTT right - is that the
main untrusted OS sets up a window, and then tells the hardware to use
a trusted surface to display to it. Presumably the driver would
configure the clip-lists for the trusted surface appropriately to
ensure that overlapping windows operate correctly, etc. The protected
domain can then use a trusted path signal (eg, sealed photo, colourful
border or whatever) to prove to the user that it's in control of the
channel.

So basically there's minimal disruption to the main OS and the MVMM
doesn't really get involved with graphics at all, except to mediate
the pagetable/nodma setup process.

> So the question is if access to the graphics hardware can be
> blocked from the untrusted mode?

My understanding is that the MVMM can block or allow whatever it likes
from the untrusted OS, however, the larger it gets the more likely
there are to be flaws, so it's better to keep the MVMM as small as
possible. I assume there's also some non-trivial context switch
overhead there.

> 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 MVMM doesn't know the hardware interface, it'd have to reverse
engineer what the untrusted OS was doing back out of the DirectX/GL
command stream. Sounds hard and slow, especially considering
programmable shaders.

This is why I think it's a better idea to let the untrusted OS handle
graphics. It already has the right software and state. The protected
domain just has to splat pixels into some region of memory and then
the GFX card working with the untrusted domain does the rest.

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

Yeah you'd have to ensure that nothing is able to leave vram whilst
the trusted surface is in operation - if an app in the untrusted OS
wanted to read the framebuffer or use a shader that writes back to
main memory, it'd get an error unless it unlinked the trusted surface
first. Ouch.

Sigh. Roll on Singularity. All this would be much easier if only we
could rewrite every program from scratch ;)