diff mbox series

drm: allow render capable master with DRM_AUTH ioctls

Message ID 20190703171001.20474-1-emil.l.velikov@gmail.com (mailing list archive)
State New, archived
Headers show
Series drm: allow render capable master with DRM_AUTH ioctls | expand

Commit Message

Emil Velikov July 3, 2019, 5:10 p.m. UTC
From: Emil Velikov <emil.velikov@collabora.com>

There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.

Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.

The former was a case for Mesa where it did not not check the return
value of drmGetMagic() [1]. That was fixed recently although, there's
the question of older drivers or other apps that exbibit this behaviour.

While omitting the call results in issues as seen in [2] and [3].

In the libva case, libva itself doesn't authenticate the DRM client and
the vaGetDisplayDRM documentation doesn't mention if the app should
either.

As of today, the official vainfo utility doesn't authenticate.

To workaround issues like these, some users resort to running their apps
under sudo. Which admittedly isn't always a good idea.

Since any DRIVER_RENDER driver has sufficient isolation between clients,
we can use that, for unauthenticated [primary node] ioctls that require
DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW.

v2:
- Rework/simplify if check (Daniel V)
- Add examples to commit messages, elaborate. (Daniel V)

v3:
- Use single unlikely (Daniel V)

v4:
- Reapply patch, check for amdgpu/radeon inline.

[1] https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136
[2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html
[3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1
Testcase: igt/core_unauth_vs_render
Cc: intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
This version effectively supersedes the DRIVER_FORCE_AUTH flag
introduced here.

https://lists.freedesktop.org/archives/dri-devel/2019-July/225165.html
https://lists.freedesktop.org/archives/dri-devel/2019-July/225166.html
---
 drivers/gpu/drm/drm_ioctl.c | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

Comments

Michel Dänzer July 4, 2019, 10:56 a.m. UTC | #1
On 2019-07-03 7:10 p.m., Emil Velikov wrote:
> From: Emil Velikov <emil.velikov@collabora.com>
> 
> There are cases (in mesa and applications) where one would open the
> primary node without properly authenticating the client.
> 
> Sometimes we don't check if the authentication succeeds, but there's
> also cases we simply forget to do it.
> 
> The former was a case for Mesa where it did not not check the return
> value of drmGetMagic() [1]. That was fixed recently although, there's
> the question of older drivers or other apps that exbibit this behaviour.
> 
> While omitting the call results in issues as seen in [2] and [3].
> 
> In the libva case, libva itself doesn't authenticate the DRM client and
> the vaGetDisplayDRM documentation doesn't mention if the app should
> either.
> 
> As of today, the official vainfo utility doesn't authenticate.
> 
> To workaround issues like these, some users resort to running their apps
> under sudo. Which admittedly isn't always a good idea.
> 
> Since any DRIVER_RENDER driver has sufficient isolation between clients,
> we can use that, for unauthenticated [primary node] ioctls that require
> DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW.
> 
> v2:
> - Rework/simplify if check (Daniel V)
> - Add examples to commit messages, elaborate. (Daniel V)
> 
> v3:
> - Use single unlikely (Daniel V)
> 
> v4:
> - Reapply patch, check for amdgpu/radeon inline.
> 
> [1] https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136
> [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html
> [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1
> Testcase: igt/core_unauth_vs_render
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

As discussed on IRC, IMHO this change requires more justification.

The system I'm writing this on has vainfo 2.4.0 installed, which opens a
render node and works fine without this change.

Similarly, if kmscube hasn't been fixed to use a render node yet, surely
it easily can.

You're asserting that the problem is wide-spread, and that fixing all
broken userspace isn't feasible, but I haven't seen any evidence
supporting that.

Since this change is essentially a workaround for broken userspace which
can never have worked, and has the potential of subverting the ongoing
transition from using primary nodes to render nodes in userspace code,
there needs to be evidence supporting that the benefit outweighs the risk.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 09f7f8e33fa3..ad7c67b89bdd 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -517,6 +517,29 @@  int drm_version(struct drm_device *dev, void *data,
 	return err;
 }
 
+static inline bool
+drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags)
+{
+	return drm_core_check_feature(dev, DRIVER_RENDER) &&
+		(flags & DRM_RENDER_ALLOW);
+}
+
+/*
+ * Yet the AMD developers have voiced concerns that by allowing ioctls
+ * such as DRM_AUTH | DRM_RENDER_ALLOW w/o enforcing DRM_AUTH developers
+ * working on the closed source user-space driver might remove render
+ * node support.
+ *
+ * Since we do _not_ want that to happen, add workaround for those two
+ * drivers.
+ */
+static inline bool
+is_amdgpu_or_radeon(const struct drm_device *dev)
+{
+	return ((dev->driver->name, "amdgpu") == 0 ||
+		(dev->driver->name, "radeon") == 0);
+}
+
 /**
  * drm_ioctl_permit - Check ioctl permissions against caller
  *
@@ -531,6 +554,8 @@  int drm_version(struct drm_device *dev, void *data,
  */
 int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
 {
+	const struct drm_device *dev = file_priv->minor->dev;
+
 	/* ROOT_ONLY is only for CAP_SYS_ADMIN */
 	if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)))
 		return -EACCES;
@@ -538,7 +563,14 @@  int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
 	/* AUTH is only for authenticated or render client */
 	if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) &&
 		     !file_priv->authenticated))
-		return -EACCES;
+		/*
+		 * Although we allow:
+		 *  - render drivers with DRM_RENDER_ALLOW ioctls, when
+		 *  - we are not using amdgpu or radeon.
+		 */
+		if (!drm_render_driver_and_ioctl(dev, flags) ||
+		    is_amdgpu_or_radeon(dev))
+			return -EACCES;
 
 	/* MASTER is only for master or control clients */
 	if (unlikely((flags & DRM_MASTER) &&