[Xorg] Any patches for X.Org release?
keith at tungstengraphics.com
Wed Aug 11 10:18:54 PDT 2004
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...
More information about the xorg