[RFC] flink_to

[Eric Anholt]

On Tue, 13 Jul 2010 08:44:22 +1000, Dave Airlie <airlied at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100713/c0ad9a12/attachment-0001.pgp>