[tboot-devel] Roadmap for trusted IO

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

Hiya,

Given that the general plan for TXT/Trusted Computing in general has
been published for ~6 years now, does Intel plan to publish a more
detailed roadmap for the technology?

In particular I'm interested in whether anybody is working on trusted
IO (graphics/keyboard) today, and if not, what has to be completed
first before it is.

This is because most of the use cases for TXT I can think of require
trusted IO in some way. After all, securely doing a calculation is
great but if the input or output to that calculation can be controlled
by the attacker, it's suddenly much less useful. I understand that VT
has some kind of support for virtualized network devices, so I guess a
MLE could have its own suite of network drivers, but network IO seems
to be one of the few things that *can* be done without special
support, by simply requiring the untrusted main OS to relay TCP/IP
packets secured with SSL. That allows for a DoS but not any other form
of tampering, which seems sufficient for most applications.

The trick is that you don't want to have to ship a set of known-good
drivers with every secure application/VM. Relying on VESA is just
going to result in a crappy user experience. That means the untrusted
main OS should be in charge of setting up and configuring nearly
everything except the trusted channel itself, then there needs to be
some protocol between the main untrusted OS and the secure VM to
finish off the last stage.

Random thought-stream from somebody who doesn't know much:

1) Main untrusted OS runs some kind of host program, which creates a
window, grabs some empty pages large enough for the framebuffer within
it, and then binds that memory to a texture. It records the physical
base address in RAM of this texture memory.

2) Untrusted host program gives away that memory to the trusted VM via
the MVMM, which ensures that now only the trusted VM can read/write to
it (and via vt-d the video card as well). It also tells the trusted VM
what the physical base address previously recorded is.

3) Trusted VM can now scribble into this framebuffer. When it's done
drawing, it context switches back to the untrusted OS which then asks
the video card to reload the texture ID given the physical base
address in RAM. There's no API to do this today in graphics drivers
because it's a useless thing, but it could be added quite easily IIUC.
Having refreshed the contents of VRAM the untrusted OS can
recomposit/rerender the screen in whatever way it likes.

4) This completes the trusted channel, without the need for
cryptography. For a trusted path, the app can unseal an image
personally selected by the user and present it to them as proof of
authenticity.

This approach is simple but has one huge problem - the untrusted OS
can simply read back the contents of VRAM like it would when taking a
screenshot, and there are the secure pixels. To stop this requires
hardware changes. There are two approaches:

1) Simple and cheap: when the video card is in "secure mode", forbid
reading back anything from vRAM into system RAM. Taking a screenshot
results in a failure or a black bitmap.
2) An S-Buffer: more complicated but more flexible. Allocate a matrix
such that each on-screen pixel has a bit. If that pixel has been
touched by the rendering of a secure texture, flip the S-Buffer bit.
When reading back from vRAM pixels with the s-buffer bit flipped are
black.

How can the trusted VM know the texture is secure? A simple
vendor-neutral hardware protocol is agreed on (reading/writing an IO
port or whatever) to indicate this. Maybe you'd write the physical
base address, size in pages, wait a few hundred microseconds, read
back the answer. The main OS driver is responsible for actually making
the texture secure in the first place, but the trusted VM can verify
that. The software knows it's talking to real hardware because the VMM
was measured.

What do you guys think?