[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen secure display

  • To: "Johnson, Tony M" <Tony.Johnson@xxxxxxxxx>, <xen-users@xxxxxxxxxxxxxxxxxxx>,<xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Mats Petersson <mats@xxxxxxxxxxxxxxxxx>
  • Date: Mon, 27 Aug 2007 22:02:38 +0100
  • Delivery-date: Mon, 27 Aug 2007 14:03:01 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:x-mailer:date:to:from:subject:in-reply-to:references:mime-version:content-type:sender:message-id; b=Am5QESb8+7endPVg3rohbEc2BkETovXyT2UOGWulS9dpQ6JatqlZf9jmVjJ5UGTYIBQU4BeVBwiPoZU4NynwqQZpNG4n1UW6Jxazq3VGDhKHuee6M2w6lQ2O8uqJINEpN04//AGtH1i6KTG8f1uKDYFpulxtr6PclN/M2WBRja0=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

At 20:20 27/08/2007, Johnson, Tony M wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;

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


Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.