Hi, On Fri, 30 Apr 2021 at 10:35, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Apr 30, 2021 at 11:08 AM Christian König > <ckoenig.leichtzumerken@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
