Re: [PATCH v2] drm: enable render-nodes by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Thomas

On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux