Hi Thomas On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom <thellstrom at 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
