On Tue, 13 Jul 2010 08:44:22 +1000, Dave Airlie airlied@redhat.com wrote:
On Mon, 2010-07-12 at 11:55 -0400, Kristian Høgsberg wrote:
[ Let's try this again... ]
...
flink_to doesn't in itself solve the security problem, since user space can still submit a batch buffer that reads or writes to an absolute gtt offset (that is, no relocation). The X front buffer location is typically pretty predictable, for example. flink_to does give us the infrastructure to implement a secure system though. There are several ways this could be done: use a sw command checker to reject absolute gtt offsets, unbind buffers from all other clients before running executing the commands or use per-process gtt or similar hw support.
Doesn't solve the security problem for *Intel*. On radeon for example we've always provided this type of security, GEM's interface is the only hole in that case (apart from the sw checker maybe missing some cases). So I'm quite happy that this is what we'd prefer.
I know Radeon's been struggling a lot with the CPU overhead of their command submission, and given that we're CPU bound for most performance stuff I look at right now, I'm not thrilled by the idea of adding command checking. Particularly the part where we have to analyze the shader kernels. I'm assuming we would disallow stateless access mode writes/reads entirely, because that lets you access arbitrary graphics memory from your instructions, and to bounds-check that you'd have to do it in shader execution and that probably means emitting an IR to the kernel instead of actual instructions.
Given that the security story today on Intel is "anybody that's authed once can access all the buffers", adding flink_to and letting people basically get authed even when not VT switched away from the X Server seems fine to me. If we want to provide these security guarantees later, then we should just unbind, or use PPGTT if available. The performance wins should be sizeable with going to PPGTT, so we need to get that done anyway.