R300 idling (new subject)

[Vladimir Dergachev]

On Sat, 18 Dec 2004, Adam Jackson wrote:

> On Saturday 18 December 2004 15:28, Vladimir Dergachev wrote:
>> On Sat, 18 Dec 2004, Adam Jackson wrote:
>>> There's a difference between safe and safe.  The DRM is responsible for
>>> anything that, if done in userspace, could lead to a root escalation.
>>> For example, if your card can DMA to arbitrary system memory, then DMA
>>> triggers need to be done on the kernel side so you don't write a 0 to
>>> current->euid.
>>>
>>> The DRM is not responsible for making sure you don't halt the GPU or the
>>> machine.
>>
>> I guess I don't see it as black and white as this. A GPU lockup usually
>> results from hardware entering a configuration outside normal operating
>> procedures. If this happens, strictly speaking, we do not know what the
>> effect may be. In particular, if one can trigger an unexplained lockup
>> it may mean that there is an intermediate state that activates DMA engine.
>>
>> Sure, this is pure speculation, but paranoia is a foundation of good
>> security model, isn't it ?
>
> Possible but highly improbable.  Usually when silicon locks up it becomes
> uncommunicative.  And if it's a lockup such that there is no further user
> interaction, then it's sort of moot what process has what privs, since the
> user can't be the attacker anymore.  Unless you're worried about random bus
> writes from the video card triggering disk writes or ethernet dumps of
> physical memory, of course...
>
> However we're faced with two intractable problems here: preventing GPU abuse,
> and getting usable documentation.  Given the choice, the best use of
> developer time is to prevent root attacks and then move on.  Unix has never
> guaranteed protection against DoS.  Neither has Windows or MacOS, for that
> matter.

I'll agree with you on this point. A lockup is effective enough deterrent 
from experimentation to find an intermediate state, sorta like a 1 minute 
delay between failed password attempts.

                         best

                            Vladimir Dergachev

>
> - ajax
>