| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen secure display
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
|
|
|
| |
|
Home