On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström <tbergstrom@xxxxxxxxxx> wrote: > On 27.11.2012 09:33, Dave Airlie wrote: >>> Third would be having a firewall in 2D driver checking the stream and >>> ensuring all registers that accept addresses are written by values >>> derived from dmabufs. I haven't tried implementing this, but it'd >>> involve a lookup table in kernel and CPU reading through the command >>> stream. Offsets and sizes would also need to be validated. There would >>> be a performance hit. >> >> This is the standard mechanism, and what exynos does as well. >> >> The per process VM method is also used as an extension to this on some hw. > > Hi, > > Thanks for the pointer, I looked at exynos code. It indeed checks the > registers written to, but it doesn't prevent overrun by checking sizes > of buffers and compare against requests. They probably need to add that, its not as important as the base addresses, unless it takes negative strides, generally base addresses means you can target current->uid quite easily! > Based on my experience with Tegra graphics stack, going through command > streams in kernel is bad for performance. For 2D operations this is > probably ok as the command streams are pretty simple. Anything more > complex is going to cause severe degradation of performance, but it's > also outside the scope of this patch set. > > If this is the way to go, I'll put the firewall behind a Kconfig flag so > that system integrator can decide if his system needs it. We don't generally make security like this optional :-) If you do that you should restrict the drm device to root users only, and never let a user with a browser anywhere near it. Like I know what you guys get away with in closed source world, but here we don't write root holes into our driver deliberately. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
