Message-ID: <5347E32B.1080002@vmware.com>
Date:	Fri, 11 Apr 2014 14:42:19 +0200
From:	Thomas Hellstrom <thellstrom@...are.com>
To:	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: DRM security flaws and security levels.

Hi,

as was discussed a while ago, there are some serious security flaws with
the current drm master model, that allows a
user that had previous access or current access to an X server terminal
to access the GPU memory of the active X server, without being
authenticated to the X server and thereby also access other user's
secret information

Scenario 1a)
User 1 uses the X server, then locks the screen. User 2 then VT
switches, perhaps using fast user-switching, opens a DRM connection and
becomes authenticated with itself. It then starts to guess GEM names
used by the switched-away X server and open the corresponding objects.
Then mmaps those objects and dumps data.

Scenario 1b)
As in 1, but instead of mmaping the GEM objects, crafts a command buffer
that dumps all GPU memory to a local buffer and copies it out.

Scenario 2
User 1 logs in on X. Starts a daemon that authenticates with X. Then
logs out. User 2 logs in. User 1's daemon can now access data in a
similar fashion to what's done in 1a and 1b.

I don't think any driver is immune against all these scenarios. I think
all GEM drivers are vulnerable to 1a) and 2a), but that could be easily
fixed by only allowing GEM open of shared buffers from the same master.
I'm not sure about 1b) and 2b) but according to the driver developers,
radeon and noveau should be safe. vmwgfx should be safe against 1) but
not currently against 2 because the DRM fd is being kept open across X
server generations.

I think these flaws can be fixed in all modern drivers. For a) type
scenarios, refuse open of shared buffers that belong to other masters,
and on new X server generations, release the old master completely by
closing the FD or a special ioctl that releases master instead of drops
master.

For b) type scenarios, either provide a command verifier, per fd virtual
GPU memory or for simpler hardware:
throw out all GPU memory on master drop and block ioctls requiring
authentication until master becomes active again.

In any case, before enabling render nodes for drm we discussed a sysfs
attribute that stated the security level of the device, so that udev
could set up permissions accordingly. My suggestion is:

-1: The driver allows an authenticated client to craft command streams
that could access any part of system memory. These drivers should be
kept in staging until they are fixed.
0: Drivers that are vulnerable to any of the above scenarios.
1: Drivers that are immune against all above scenarios but allows any
authenticated client with *active* master to access all GPU memory. Any
enabled render nodes will be insecure, while primary nodes are secure.
2: Drivers that are immune against all above scenarios and can protect
clients from accessing eachother's gpu memory:
Render nodes will be secure.

Thoughts?

Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists