Removing direct graphics access from DGA

[Keith Packard]

On Thu, 2009-09-17 at 10:24 +1000, Dave Airlie wrote:

> As long as someone tests quake 1 still works ;-)

Ok, the DGA situation is actually worse than I thought. Any driver
supporting framebuffer resizing that uses the xf86DiDGAInit function
will expose the system to potentially catastrophic failures. 

The xf86DiDGAInit function takes a static address (in the server's
address space) for the base of the scanout buffer. This value is given
to clients to mmap from /dev/mem themselves.

It's important to note here that we're returning a random internal X
server address space value to applications and encouraging them to mmap
that part of CPU physical address space and write pixels there. Clearly,
this code hasn't ever been used by an application as it could never have
worked.

The other operation that DGA supports is to offer a few rendering
operations on the framebuffer as well as the ability to create a pixmap
representing the framebuffer for use by regular X drawing functions. I'm
betting the only client using this is the DGA2 example application
'skull_dga' -- it's not exactly a compelling use case (a magic mechanism
to create a drawable representing the screen just doesn't seem
interesting to me). I know that when I googled around, I couldn't find
anything other than the DGA man page referencing these functions.

I'm sure this could all be fixed with sufficient energy and time, but I
suggest that it would be better to just not do this anymore and leave
DGA as a way for old applications to switch video modes and get direct
mouse input. For these two operations, it seems to work just fine
(although I did manage to uncover a bug in the intel driver for DGA mode
switching).

The trick, however, is how to make these 'safe' operations available
while not exposing the 'bad' parts. The xf86DiDGA code doesn't allow
this -- you either get all of DGA, including the bad parts, or you get
none of it. So, a cautious driver must never initialize DGA for fear
that it will be run against an old X server.

The solution that I came up with is to have xf86CrtcInit call
xf86DiDGAInit and remove the call to xf86DiDGAInit from the video
driver. Thus, the driver running against an old server gets no DGA
(ether bad or safe parts) and when run against a new server gets just
the safe parts.

I've tested this with gl-117 and warsow, both of which appear to use DGA
input. Additional testing is encouraged, of course.

I don't think this patch is 'optional' for either X server 1.7 or 1.6.4;
it removes the potential for some fairly serious system-wide
consequences while appearing to keep existing applications running.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-xfree86-modes-Remove-all-framebuffer-support-from-DG.patch
Type: text/x-patch
Size: 8106 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090918/bd8991a0/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20090918/bd8991a0/attachment.pgp