[Xorg] Any patches for X.Org release?

[Keith Whitwell]

Alan Cox wrote:
> On Mer, 2004-08-11 at 01:29, Dave Airlie wrote:
> 
>>>Can the VIA DRI stuff get pushed through to the kernel with the S3
>>>stuff please, even if we mark VIA as experimental
>>
>>the DRM stuff? We need to mark as insecure, I really don't want anything
>>that the authors consider insecure to go anywhere outside the DRM...
> 
> 
> Who considers it insecure and where is it documented then I'll go and
> have a look at the issue. I keep hearing indirect references to this but
> nobody ever answering in detail.

In general the issue is with chips that can write back to system memory or 
read from it in one way or another.

There are two broad categories for this: 1) using the blit or dma engine and 
2) 'status' writebacks.

1) is pretty obvious - there are cards which can target regular memory taking 
physical addresses for blits, render targets, whatever.

2) refers to cards which have 'breadcrumb' or other helpful mechanisms which 
write back a word or two of status data to some physical address in main 
memory so that drivers can avoid polling the card.

If either of these can be set up & activated by the command stream exposed to 
the DRI client, the card is considered insecure.

One way we've tried to operate is to seperate geometry/triangle data from 
general commands, which the driver legitimately wants to use to set state, but 
which could be used maliciously for the purposes above.  A lot of hardware 
allows geometry data to be passed via seperate mechanisms from the general 
command stream, so we can, eg. put vertices in an agp buffer while passing a 
command stream or abstracted packets to the kernel for verification before 
handing off to hardware.

This depends on the existence of a method for passing vertex data seperately 
from other commands.  The mach64, for example, doesn't have such a mechanism, 
vertex data looks just like other commands & has to go through the same 
stream.  This is when passing data through the kernel starts to look daunting, 
as it *all* has to go that route and be verified along the way.

That said, in the current i915 driver, I've got just such a pathway, which 
I've tested (on fast CPU's) and it wasn't too bad...

Keith