On 03/20/2014 08:36 AM, David Herrmann wrote: > Hi > > On Thu, Mar 20, 2014 at 7:43 AM, Thomas Hellstrom <thomas@xxxxxxxxxxxx> wrote: >> On 03/17/2014 05:43 PM, David Herrmann wrote: >>> We introduced render-nodes about 1/2 year ago and no problems showed up. >>> Remove the drm_rnodes argument and enable them by default now. >> So what about the malicious execbuf command stream problem? Do we >> require all drivers that enable >> render-nodes to have a mechanism to prevent this in place? > No, that's no requirement. Render-nodes provide a secure API, if the > underlying driver does no command-stream validation (I guess for > performance-reasons and lack of VM), it's an implementation detail, > not an API. Furthermore, you can always set higher restrictions on the > render-node char-dev in case this bothers you. I'm merely trying to envision the situation where a distro wants to create, for example an udev rule for the render nodes. How should the distro know that the implementation is not insecure? Historically drm has refused to upstream drivers without a proper command validation mechanism in place (via for example), but that validation mechanism only needed to make sure no random system memory was ever accessible to an authenticated DRM client. Now, render nodes are designed to provide also user data isolation. But if we allow insecure implementations, wouldn't that compromise the whole idea? Now that we have a secure API within reach, wouldn't it be reasonable to require implementations to also be secure, following earlier DRM practices? Or am I missing something? /Thomas > > Cheers > David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
