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