Re: [Xen-devel] Xen secure display

[Mats Petersson <mats@xxxxxxxxxxxxxxxxx>]

At 20:20 27/08/2007, Johnson, Tony M wrote:
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C7E8DF.4985A31E"
>
> What solutions are available to provide a completely secure display 
> system so that users can be sure that what they see on screen is 
> what they are supposed to see, and that no-one can eavesdrop on 
> what's being displayed?
As far as I'm aware, there is no support for this in Xen, and most of 
the vulnerabilities that allow "screen eavesdropping" are based on 
X-windows "holes" (intentional or otherwise), and this is not passed 
through Xen in the first place, it is managed by Dom0 that owns the 
graphics hardware (or if you pass the graphics hardware to another 
domain, that domain is handling the graphics). This applies to 
para-virtual display.
In the case of a fully virtual solution the display is handled as a 
"framebuffer device" via QEMU and SDL or VNC, but in principle that 
is just DISPLAYING whatever has been drawn on the screen by whatever 
OS is being run there, so it's "stupid" in the sense that QEMU 
doesn't have any clue about what applications are supposed to 
read/write to the screen memory, or what is expected to appear on 
screen - if you an application is able to read (eavesdropping or 
"print-screen" functions for example) in native solution, the same 
will apply under Xen.
It would probably not be easy to determine within the hypervisor if a 
read of the screen is valid or not -  the hypervisor can't tell the 
difference between an application saving part of the current screen 
content for it's own internal reason[1], or if it's doing so for 
illicit reasons. The hypervisor also don't actually know much about 
what the guest is actually doing in the sense of which application is 
running or what the application should or shouldn't be able to do.
This sort of functionality is more likely to be best placed in a 
software running as part of the guest (similar to anti-virus software 
for example), and using some sort of filter graphcis driver or 
virtual screen device that filters screen read/write requests based 
on application identity (not necessarily the name, as anyone can 
rename the application to "notepad" or "internet explorer" if they 
try hard enough).
This is my limited understanding of the subject based on my work on 
the Xen Hypervisor and working with Windows Graphics drivers - I have 
not studied the subject of "secure display" specifically, so there 
may be other experts out there that can add further details on that subject.
[1] There are many different circumstances when the frame buffer is 
being read for perfectly "legal" reasons, the most obvious being when 
the graphics hardware can't do something (or the driver writer 
decided that it wasn't meaningful to make the HARDWARE do something), 
and the functionality is "punted" back to Windows. If windows needs 
to draw something that is dependant on for example the background 
it's drawing on, then it will need to read the background first, then 
update that in it's local buffer, and copy back the updated version 
of those pixels. This is quite commonly done in most drivers for the 
more obscure functionality (or when the hardware for something is 
broken - say some particular hardware unit has a bug that was 
detected only after the chip has gone into production, the 
functionality may just be taken out of the driver and punted back to 
Windows to avoid the hardware bug).
--
Mats

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel