R300 idling (new subject)
Vladimir Dergachev
volodya at mindspring.com
Sat Dec 18 10:53:58 PST 2004
On Sat, 18 Dec 2004, Adam Jackson wrote:
> On Saturday 18 December 2004 03:27, Vladimir Dergachev wrote:
>>>>>> do things is to do a proper cache flush (plus whatever magic is
>>>>>> required) each time 3d activity is followed by 2d one.
>>>>>
>>>>> So is emitting the cache flush(es) in EnterServer() not enough?
>>>>
>>>> No. A user-space client is perfectly entitled to mix 2d and 3d code
>>>> and a proper DRM driver must be able to prevent lockups in case
>>>> user-space client screws up.
>>>
>>> We've never guaranteed "prevent lockups in case user-space client screws
>>> up" before. Generally reducing lockups in that case is nice, I'd say,
>>> but the "must" would be a new requirement.
>>
>> Oh.. This would mean we gave up on security, I hope it is not true..
>
> Our security model is, if you have access to /dev/dri/card? and the X server
> let you connect, then you can write directly to the hardware. There are
> plenty of other DoS attacks you can perform once you have a connection to the
> server.
I thought that we only let the Mesa driver access "safe" registers and the
rest was done through DRM driver. I understand that many drivers access
video memory directly, but my impression was that this was a compromise to
deliver a working driver earlier and/or for suboptimal hardware.
>
> Don't like it? Help me figure out accelerated indirect rendering, which would
> let you restrict drm device access to root (the server) and still get
> accelerated 3d.
This might be fun :) What are the current issues ? Is there a place I can
read about them ?
best
Vladimir Dergachev
>
> - ajax
>
More information about the xorg
mailing list