linux-kernel - Re: [PATCH 1/4] drm/v3d: Delay the scheduler timeout if we're still making progress.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k1q97h5v.fsf@anholt.net>
Date:   Thu, 05 Jul 2018 09:59:08 -0700
From:   Eric Anholt <eric@...olt.net>
To:     Lucas Stach <l.stach@...gutronix.de>,
        dri-devel@...ts.freedesktop.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] drm/v3d: Delay the scheduler timeout if we're still making progress.

Lucas Stach <l.stach@...gutronix.de> writes:

> Am Dienstag, den 03.07.2018, 10:05 -0700 schrieb Eric Anholt:
>> GTF-GLES2.gtf.GL.acos.acos_float_vert_xvary submits jobs that take 4
>> seconds at maximum resolution, but we still want to reset quickly if a
>> job is really hung.  Sample the CL's current address and the return
>> address (since we call into tile lists repeatedly) and if either has
>> changed then assume we've made progress.
>
> So this means you are doubling your timeout? AFAICS for the first time
> you hit the timeout handler the cached ctca and ctra values will
> probably always differ from the current values. Maybe this warrants a
> mention in the commit message, as it's changing the behavior of the
> scheduler timeout.

I supposes that doubles the minimum timeout, but I don't think there's
any principled choice behind that value.

> Also how easy is it for userspace to construct such an infinite loop in
> the CL? Thinking about a rogue client DoSing the GPU while exploiting
> this check in the timeout handler to stay under the radar...

You'd need to have a big enough CL that you don't sample the same
location twice in a row, but otherwise it's trivial and equivalent to a
V3D33 igt case I wrote.  I don't think we as the kernel particularly
cares to protect from that case, though -- it's mainly "does a broken
WebGL shader take down your desktop?" which we will still be protecting
from.  If you wanted to protect from a general userspace attacker, you
could have a maximum 1 minute timeout or something, but I'm not sure
your life is actually much better when you let an arbitrary number of
clients submit many jobs to round-robin through each of which has a long
timeout like that.

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)