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

[Thomas Hellstrom <thellstrom@vmware.com>]

On 03/20/2014 10:05 AM, David Herrmann wrote:
> 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

OK, let me give one example:

A user logs in to a system where DRI clients use render nodes. The
system grants rw permission on the render nodes for the console user. 
User starts editing a secret document, starts some GPGPU structural FEM
computations of  the Pentagon building. Locks the screen and goes for lunch.

A malicious user logs in using fast user switching and becomes the owner
of the render node. Tries to map a couple of random offsets, but that
fails, due to security checks. Now crafts a malicious command stream to
dump all GPU memory to a file. Steals the first user's secret document
and the intermediate Pentagon data. Logs out and starts data mining.

Now if we require drivers to block these malicious command streams this
can never happen, and distros can reliably grant rw access to the render
nodes to the user currently logged into the console.

I guest basically what I'm trying to say that with the legacy concept it
was OK to access all GPU memory, because an authenticated X user
basically had the same permissions.

With render nodes we're allowing multiple users into the GPU at the same
time, and it's not OK anymore for a client to access another clients GPU
buffer through a malicious command stream.

/Thomas