Hi Thomas
On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom thellstrom@vmware.com wrote:
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.
I expect all drivers to protect system-memory. All that I am talking about is one exec-buffer writing to memory of another _GPU_ buffer that this client doesn't have access to. But maybe driver authors can give some insights. I'd even expect non-texture/data GPU buffers to be protected.
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?
I don't understand what this has to do with render-nodes? The API _is_ secure. What would be the gain of disabling render-nodes for broken (even deliberately) drivers? User-space is not going to assume drivers are broken and rely on hand-crafted exec-buffers that cross buffer boundaries. So yes, we're fooling our selves with API guarantees that drivers cannot deliver, but what's the downside?
Thanks David