Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Daniel Stone <daniel@fooishbar.org>]

Hi,

On Fri, 30 Apr 2021 at 10:35, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Apr 30, 2021 at 11:08 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
> > This doesn't work in hardware. We at least need to setup a few registers
> > and memory locations from inside the VM which userspace shouldn't have
> > access to when we want the end of batch fence and ring buffer start to
> > be reliable.
>
> The thing is, we don't care whether it's reliable or not. Userspace is
> allowed to lie, not signal, signal the wrong thing, out of order,
> everything.
>
> The design assumes all this is possible.
>
> So unless you can't signal at all from userspace, this works. And for
> the "can't signal at all" it just means something needs to do a cpu
> busy wait and burn down lots of cpu time. I hope that's not your hw
> design :-)

I've been sitting this one out so far because what other-Dan's
proposed seems totally sensible and workable for me, so I'll let him
argue it rather than confuse it.

But - yes. Our threat model does not care about a malicious content
which deliberately submits garbage and then gets the compositor to
display garbage. If that's the attack then you could just emit noise
from your frag shader.

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel