[RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Emil Velikov]

From: Emil Velikov <emil.velikov@collabora.com>

This commit reworks the permission handling of the two ioctls. In
particular it enforced the CAP_SYS_ADMIN check only, if:
 - we're issuing the ioctl from process other than the one which opened
the node, and
 - we are, or were master in the past

This allows for any application which cannot rely on systemd-logind
being present (for whichever reason), to drop it's master capabilities
(and regain them at later point) w/o being ran as root.

See the comment above drm_master_check_perm() for more details.

Cc: Adam Jackson <ajax@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
---
This effectively supersedes an earlier patch [1] incorporating ajax's
feedback (from IRC ages ago).

[1] https://patchwork.freedesktop.org/patch/268977/
---
 drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/drm_ioctl.c |  4 +--
 include/drm/drm_file.h      | 11 +++++++
 3 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index cc9acd986c68..01d9e35c0106 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -135,6 +135,7 @@ static int drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
 		}
 	}
 
+	fpriv->was_master = (ret == 0);
 	return ret;
 }
 
@@ -179,12 +180,64 @@ static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
 	return ret;
 }
 
+/*
+ * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
+ * CAP_SYS_ADMIN was not set.
+ *
+ * Even though the first client is _always_ master, it also had to be run as
+ * root, otherwise SET/DROP_MASTER would fail. In those cases no other client
+ * could become master ... EVER.
+ *
+ * Resulting in a) the graphics session dying badly or b) a completely locked
+ * session :-\
+ *
+ * As some point systemd-logind was introduced to orchestrate and delegate
+ * master as applicable. It does so by opening the fd and passing it to users
+ * while in itself logind a) set/drop master per users' request and b)
+ * implicitly drops master on VT switch.
+ *
+ * Even though logind looks like the future, there are a few obstacles:
+ *  - using it is not possible on some platforms, or
+ *  - applications may not be updated to use it,
+ *  - any client which fails to drop master* can DoS the application using
+ * logind, to a varying degree.
+ *
+ * * Either due missing root permission or simply not calling DROP_MASTER.
+ *
+ *
+ * Here we implement the next best thing:
+ *   We enforce the CAP_SYS_ADMIN check only if the client was not a master
+ * before. We distinguish between the original master client (say logind) and
+ * another client which has the fd passed (say Xorg) by comparing the pids.
+ *
+ * As a result this fixes, the following when using root-less build w/o logind
+ * - startx - some drivers work fine regardless
+ * - weston
+ * - various compositors based on wlroots
+ */
+static int
+drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
+{
+	if (file_priv->pid != task_pid(current) && file_priv->was_master)
+		return 0;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	return 0;
+}
+
 int drm_setmaster_ioctl(struct drm_device *dev, void *data,
 			struct drm_file *file_priv)
 {
 	int ret = 0;
 
 	mutex_lock(&dev->master_mutex);
+
+	ret = drm_master_check_perm(dev, file_priv);
+	if (ret)
+		goto out_unlock;
+
 	if (drm_is_current_master(file_priv))
 		goto out_unlock;
 
@@ -229,6 +282,12 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
 	int ret = -EINVAL;
 
 	mutex_lock(&dev->master_mutex);
+
+	ret = drm_master_check_perm(dev, file_priv);
+	if (ret)
+		goto out_unlock;
+
+	ret = -EINVAL;
 	if (!drm_is_current_master(file_priv))
 		goto out_unlock;
 
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 9e41972c4bbc..73e31dd4e442 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -599,8 +599,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
 	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_legacy_setsareactx, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_legacy_getsareactx, DRM_AUTH),
 
-	DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
-	DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, DRM_ROOT_ONLY),
+	DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, 0),
+	DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, 0),
 
 	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_ADD_CTX, drm_legacy_addctx, DRM_AUTH|DRM_ROOT_ONLY),
 	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_RM_CTX, drm_legacy_rmctx, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 19df8028a6c4..c4746c9d3619 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -201,6 +201,17 @@ struct drm_file {
 	 */
 	bool writeback_connectors;
 
+	/**
+	 * @was_master:
+	 *
+	 * This client has or had, master capability. Protected by struct
+	 * &drm_device.master_mutex.
+	 *
+	 * This is used to ensure that CAP_SYS_ADMIN is not enforced, if the
+	 * client is or was master in the past.
+	 */
+	bool was_master;
+
 	/**
 	 * @is_master:
 	 *
-- 
2.25.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Daniel Vetter]

On Wed, Feb 05, 2020 at 05:48:39PM +0000, Emil Velikov wrote:
> From: Emil Velikov <emil.velikov@collabora.com>
> 
> This commit reworks the permission handling of the two ioctls. In
> particular it enforced the CAP_SYS_ADMIN check only, if:
>  - we're issuing the ioctl from process other than the one which opened
> the node, and
>  - we are, or were master in the past
> 
> This allows for any application which cannot rely on systemd-logind
> being present (for whichever reason), to drop it's master capabilities
> (and regain them at later point) w/o being ran as root.
> 
> See the comment above drm_master_check_perm() for more details.
> 
> Cc: Adam Jackson <ajax@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> ---
> This effectively supersedes an earlier patch [1] incorporating ajax's
> feedback (from IRC ages ago).
> 
> [1] https://patchwork.freedesktop.org/patch/268977/
> ---
>  drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/drm_ioctl.c |  4 +--
>  include/drm/drm_file.h      | 11 +++++++
>  3 files changed, 72 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index cc9acd986c68..01d9e35c0106 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -135,6 +135,7 @@ static int drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
>  		}
>  	}
>  
> +	fpriv->was_master = (ret == 0);
>  	return ret;
>  }
>  
> @@ -179,12 +180,64 @@ static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
>  	return ret;
>  }
>  
> +/*
> + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
> + * CAP_SYS_ADMIN was not set.
> + *
> + * Even though the first client is _always_ master, it also had to be run as
> + * root, otherwise SET/DROP_MASTER would fail. In those cases no other client
> + * could become master ... EVER.
> + *
> + * Resulting in a) the graphics session dying badly or b) a completely locked
> + * session :-\
> + *
> + * As some point systemd-logind was introduced to orchestrate and delegate
> + * master as applicable. It does so by opening the fd and passing it to users
> + * while in itself logind a) set/drop master per users' request and b)
> + * implicitly drops master on VT switch.
> + *
> + * Even though logind looks like the future, there are a few obstacles:
> + *  - using it is not possible on some platforms, or
> + *  - applications may not be updated to use it,
> + *  - any client which fails to drop master* can DoS the application using
> + * logind, to a varying degree.
> + *
> + * * Either due missing root permission or simply not calling DROP_MASTER.
> + *
> + *
> + * Here we implement the next best thing:
> + *   We enforce the CAP_SYS_ADMIN check only if the client was not a master
> + * before. We distinguish between the original master client (say logind) and
> + * another client which has the fd passed (say Xorg) by comparing the pids.
> + *
> + * As a result this fixes, the following when using root-less build w/o logind
> + * - startx - some drivers work fine regardless
> + * - weston
> + * - various compositors based on wlroots
> + */

I think this breaks logind security. With logind no compositor can open
the device node directly, hence no compositor can accidentally become the
master and block everyone else.

And for the vt switch logind is the only one that can grant master rights,
and it can make sure that the right compositor gets them. And if the old
compositor is non-cooperating, it can also forcefully remove master
rights.

But with this here we lift this restriction if a compositor has ever been
master. So the following thing could happen:
- We have 3 compositors for different users C1, C2, C3
- We switch from C1 to C2
- While we switch no one is master for a moment, which means C3 could
  sneak in and do a quick setmaster, and become master
- Everything would come crashing done since logind believes it already
  revoked master for C1, but somehow it now cant grant master to C2

I'm not sure we can even support these two models at the same time.

> +static int
> +drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> +{
> +	if (file_priv->pid != task_pid(current) && file_priv->was_master)

Isn't this a typo? Why should we only allow this if the opener is someone
else ... that looks like the logind approach? Or is my bolean logic parser
broken again.

Cheers, Daniel

> +		return 0;
> +
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EACCES;
> +
> +	return 0;
> +}
> +
>  int drm_setmaster_ioctl(struct drm_device *dev, void *data,
>  			struct drm_file *file_priv)
>  {
>  	int ret = 0;
>  
>  	mutex_lock(&dev->master_mutex);
> +
> +	ret = drm_master_check_perm(dev, file_priv);
> +	if (ret)
> +		goto out_unlock;
> +
>  	if (drm_is_current_master(file_priv))
>  		goto out_unlock;
>  
> @@ -229,6 +282,12 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
>  	int ret = -EINVAL;
>  
>  	mutex_lock(&dev->master_mutex);
> +
> +	ret = drm_master_check_perm(dev, file_priv);
> +	if (ret)
> +		goto out_unlock;
> +
> +	ret = -EINVAL;
>  	if (!drm_is_current_master(file_priv))
>  		goto out_unlock;
>  
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 9e41972c4bbc..73e31dd4e442 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -599,8 +599,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>  	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_legacy_setsareactx, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>  	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_legacy_getsareactx, DRM_AUTH),
>  
> -	DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
> -	DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, DRM_ROOT_ONLY),
> +	DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, 0),
> +	DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, 0),
>  
>  	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_ADD_CTX, drm_legacy_addctx, DRM_AUTH|DRM_ROOT_ONLY),
>  	DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_RM_CTX, drm_legacy_rmctx, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 19df8028a6c4..c4746c9d3619 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -201,6 +201,17 @@ struct drm_file {
>  	 */
>  	bool writeback_connectors;
>  
> +	/**
> +	 * @was_master:
> +	 *
> +	 * This client has or had, master capability. Protected by struct
> +	 * &drm_device.master_mutex.
> +	 *
> +	 * This is used to ensure that CAP_SYS_ADMIN is not enforced, if the
> +	 * client is or was master in the past.
> +	 */
> +	bool was_master;
> +
>  	/**
>  	 * @is_master:
>  	 *
> -- 
> 2.25.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Emil Velikov]

Thanks for having a look Daniel.

On Fri, 7 Feb 2020 at 13:29, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Feb 05, 2020 at 05:48:39PM +0000, Emil Velikov wrote:
> > From: Emil Velikov <emil.velikov@collabora.com>
> >
> > This commit reworks the permission handling of the two ioctls. In
> > particular it enforced the CAP_SYS_ADMIN check only, if:
> >  - we're issuing the ioctl from process other than the one which opened
> > the node, and
> >  - we are, or were master in the past
> >
> > This allows for any application which cannot rely on systemd-logind
> > being present (for whichever reason), to drop it's master capabilities
> > (and regain them at later point) w/o being ran as root.
> >
> > See the comment above drm_master_check_perm() for more details.
> >
> > Cc: Adam Jackson <ajax@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> > ---
> > This effectively supersedes an earlier patch [1] incorporating ajax's
> > feedback (from IRC ages ago).
> >
> > [1] https://patchwork.freedesktop.org/patch/268977/
> > ---
> >  drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/drm_ioctl.c |  4 +--
> >  include/drm/drm_file.h      | 11 +++++++
> >  3 files changed, 72 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > index cc9acd986c68..01d9e35c0106 100644
> > --- a/drivers/gpu/drm/drm_auth.c
> > +++ b/drivers/gpu/drm/drm_auth.c
> > @@ -135,6 +135,7 @@ static int drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
> >               }
> >       }
> >
> > +     fpriv->was_master = (ret == 0);
> >       return ret;
> >  }
> >
> > @@ -179,12 +180,64 @@ static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
> >       return ret;
> >  }
> >
> > +/*
> > + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
> > + * CAP_SYS_ADMIN was not set.
> > + *
> > + * Even though the first client is _always_ master, it also had to be run as
> > + * root, otherwise SET/DROP_MASTER would fail. In those cases no other client
> > + * could become master ... EVER.
> > + *
> > + * Resulting in a) the graphics session dying badly or b) a completely locked
> > + * session :-\
> > + *
> > + * As some point systemd-logind was introduced to orchestrate and delegate
> > + * master as applicable. It does so by opening the fd and passing it to users
> > + * while in itself logind a) set/drop master per users' request and b)
> > + * implicitly drops master on VT switch.
> > + *
> > + * Even though logind looks like the future, there are a few obstacles:
> > + *  - using it is not possible on some platforms, or
> > + *  - applications may not be updated to use it,
> > + *  - any client which fails to drop master* can DoS the application using
> > + * logind, to a varying degree.
> > + *
> > + * * Either due missing root permission or simply not calling DROP_MASTER.
> > + *
> > + *
> > + * Here we implement the next best thing:
> > + *   We enforce the CAP_SYS_ADMIN check only if the client was not a master
> > + * before. We distinguish between the original master client (say logind) and
> > + * another client which has the fd passed (say Xorg) by comparing the pids.
> > + *
> > + * As a result this fixes, the following when using root-less build w/o logind
> > + * - startx - some drivers work fine regardless
> > + * - weston
> > + * - various compositors based on wlroots
> > + */
>
> I think this breaks logind security. With logind no compositor can open
> the device node directly, hence no compositor can accidentally become the
> master and block everyone else.
>
I've explicitly considered this case. AFAICT this patch does not
change any of the contract.
If you think there's a scenario where things have broken, please let me know.

> And for the vt switch logind is the only one that can grant master rights,
> and it can make sure that the right compositor gets them. And if the old
> compositor is non-cooperating, it can also forcefully remove master
> rights.
>
Yes logind does set/drop master on VT switch, session setup/teardown, etc.

To take this a step further, there is no logind API or dbus method for
compositors to only set/drop master.
Thus logind ensures that compositors are in sane state.

> But with this here we lift this restriction if a compositor has ever been
> master. So the following thing could happen:
> - We have 3 compositors for different users C1, C2, C3
> - We switch from C1 to C2
> - While we switch no one is master for a moment, which means C3 could
>   sneak in and do a quick setmaster, and become master
> - Everything would come crashing done since logind believes it already
>   revoked master for C1, but somehow it now cant grant master to C2
>
Does this scenario consider that all three compositors are logind users?
If so, C3 should not be able to set or drop master. Since it got its
fd from logind:

 - `file_priv->pid` will point to systemd-logind, and
 - `task_pid(current)` will point to the respective compositor

-> EACCES will be returned to any compositor calling drmSetMaster.

Regardless of my patch, C3 can open() and simply not release the master.
Assuming it's the first DRM client of course - say switch to VTx +
login + start C3.

I've been lucky enough to spot various ways to softlock my system...
even when the compositor is using logind ;-)
If you're really interested I can share, but I'm worried that people
may see them as bashing at logind.

> I'm not sure we can even support these two models at the same time.
>
> > +static int
> > +drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> > +{
> > +     if (file_priv->pid != task_pid(current) && file_priv->was_master)
>
> Isn't this a typo? Why should we only allow this if the opener is someone
> else ... that looks like the logind approach? Or is my bolean logic parser
> broken again.
>
Thanks for spotting it. Indeed that should be:

if (file_priv->pid == task_pid(current) && file_priv->was_master)
    return 0;


Modulo any objections, I'll do proper testing and submit a non RFC version.
The inline comments will explicitly mention your concerns and why the
patch is safe.


Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Daniel Vetter]

On Mon, Feb 10, 2020 at 8:01 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> Thanks for having a look Daniel.
>
> On Fri, 7 Feb 2020 at 13:29, Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Wed, Feb 05, 2020 at 05:48:39PM +0000, Emil Velikov wrote:
> > > From: Emil Velikov <emil.velikov@collabora.com>
> > >
> > > This commit reworks the permission handling of the two ioctls. In
> > > particular it enforced the CAP_SYS_ADMIN check only, if:
> > >  - we're issuing the ioctl from process other than the one which opened
> > > the node, and
> > >  - we are, or were master in the past
> > >
> > > This allows for any application which cannot rely on systemd-logind
> > > being present (for whichever reason), to drop it's master capabilities
> > > (and regain them at later point) w/o being ran as root.
> > >
> > > See the comment above drm_master_check_perm() for more details.
> > >
> > > Cc: Adam Jackson <ajax@redhat.com>
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> > > ---
> > > This effectively supersedes an earlier patch [1] incorporating ajax's
> > > feedback (from IRC ages ago).
> > >
> > > [1] https://patchwork.freedesktop.org/patch/268977/
> > > ---
> > >  drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
> > >  drivers/gpu/drm/drm_ioctl.c |  4 +--
> > >  include/drm/drm_file.h      | 11 +++++++
> > >  3 files changed, 72 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > index cc9acd986c68..01d9e35c0106 100644
> > > --- a/drivers/gpu/drm/drm_auth.c
> > > +++ b/drivers/gpu/drm/drm_auth.c
> > > @@ -135,6 +135,7 @@ static int drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
> > >               }
> > >       }
> > >
> > > +     fpriv->was_master = (ret == 0);
> > >       return ret;
> > >  }
> > >
> > > @@ -179,12 +180,64 @@ static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
> > >       return ret;
> > >  }
> > >
> > > +/*
> > > + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
> > > + * CAP_SYS_ADMIN was not set.
> > > + *
> > > + * Even though the first client is _always_ master, it also had to be run as
> > > + * root, otherwise SET/DROP_MASTER would fail. In those cases no other client
> > > + * could become master ... EVER.
> > > + *
> > > + * Resulting in a) the graphics session dying badly or b) a completely locked
> > > + * session :-\
> > > + *
> > > + * As some point systemd-logind was introduced to orchestrate and delegate
> > > + * master as applicable. It does so by opening the fd and passing it to users
> > > + * while in itself logind a) set/drop master per users' request and b)
> > > + * implicitly drops master on VT switch.
> > > + *
> > > + * Even though logind looks like the future, there are a few obstacles:
> > > + *  - using it is not possible on some platforms, or
> > > + *  - applications may not be updated to use it,
> > > + *  - any client which fails to drop master* can DoS the application using
> > > + * logind, to a varying degree.
> > > + *
> > > + * * Either due missing root permission or simply not calling DROP_MASTER.
> > > + *
> > > + *
> > > + * Here we implement the next best thing:
> > > + *   We enforce the CAP_SYS_ADMIN check only if the client was not a master
> > > + * before. We distinguish between the original master client (say logind) and
> > > + * another client which has the fd passed (say Xorg) by comparing the pids.
> > > + *
> > > + * As a result this fixes, the following when using root-less build w/o logind
> > > + * - startx - some drivers work fine regardless
> > > + * - weston
> > > + * - various compositors based on wlroots
> > > + */
> >
> > I think this breaks logind security. With logind no compositor can open
> > the device node directly, hence no compositor can accidentally become the
> > master and block everyone else.
> >
> I've explicitly considered this case. AFAICT this patch does not
> change any of the contract.
> If you think there's a scenario where things have broken, please let me know.
>
> > And for the vt switch logind is the only one that can grant master rights,
> > and it can make sure that the right compositor gets them. And if the old
> > compositor is non-cooperating, it can also forcefully remove master
> > rights.
> >
> Yes logind does set/drop master on VT switch, session setup/teardown, etc.
>
> To take this a step further, there is no logind API or dbus method for
> compositors to only set/drop master.
> Thus logind ensures that compositors are in sane state.
>
> > But with this here we lift this restriction if a compositor has ever been
> > master. So the following thing could happen:
> > - We have 3 compositors for different users C1, C2, C3
> > - We switch from C1 to C2
> > - While we switch no one is master for a moment, which means C3 could
> >   sneak in and do a quick setmaster, and become master
> > - Everything would come crashing done since logind believes it already
> >   revoked master for C1, but somehow it now cant grant master to C2
> >
> Does this scenario consider that all three compositors are logind users?
> If so, C3 should not be able to set or drop master. Since it got its
> fd from logind:
>
>  - `file_priv->pid` will point to systemd-logind, and
>  - `task_pid(current)` will point to the respective compositor
>
> -> EACCES will be returned to any compositor calling drmSetMaster.
>
> Regardless of my patch, C3 can open() and simply not release the master.
> Assuming it's the first DRM client of course - say switch to VTx +
> login + start C3.

Hm ... I guess this works indeed. Or should. I'm mildly freaked out
that we're checking for opener_pid == current->pid. Not sure how many
other security assumptions we're breaking.

> I've been lucky enough to spot various ways to softlock my system...
> even when the compositor is using logind ;-)
> If you're really interested I can share, but I'm worried that people
> may see them as bashing at logind.
>
> > I'm not sure we can even support these two models at the same time.
> >
> > > +static int
> > > +drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> > > +{
> > > +     if (file_priv->pid != task_pid(current) && file_priv->was_master)
> >
> > Isn't this a typo? Why should we only allow this if the opener is someone
> > else ... that looks like the logind approach? Or is my bolean logic parser
> > broken again.
> >
> Thanks for spotting it. Indeed that should be:
>
> if (file_priv->pid == task_pid(current) && file_priv->was_master)
>     return 0;
>
>
> Modulo any objections, I'll do proper testing and submit a non RFC version.
> The inline comments will explicitly mention your concerns and why the
> patch is safe.

Given the above bug I think a solid igt for both the logind and the
non-logind scenario is needed. We have some helpers to drop root and
fork stuff and all that, so shouldn't be many lines.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 2738 bytes --]

On Mon, 10 Feb 2020 19:01:06 +0000
Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Thanks for having a look Daniel.
> 
> On Fri, 7 Feb 2020 at 13:29, Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Wed, Feb 05, 2020 at 05:48:39PM +0000, Emil Velikov wrote:  
> > > From: Emil Velikov <emil.velikov@collabora.com>
> > >
> > > This commit reworks the permission handling of the two ioctls. In
> > > particular it enforced the CAP_SYS_ADMIN check only, if:
> > >  - we're issuing the ioctl from process other than the one which opened
> > > the node, and
> > >  - we are, or were master in the past
> > >
> > > This allows for any application which cannot rely on systemd-logind
> > > being present (for whichever reason), to drop it's master capabilities
> > > (and regain them at later point) w/o being ran as root.
> > >
> > > See the comment above drm_master_check_perm() for more details.
> > >
> > > Cc: Adam Jackson <ajax@redhat.com>
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> > > ---
> > > This effectively supersedes an earlier patch [1] incorporating ajax's
> > > feedback (from IRC ages ago).
> > >
> > > [1] https://patchwork.freedesktop.org/patch/268977/
> > > ---
> > >  drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
> > >  drivers/gpu/drm/drm_ioctl.c |  4 +--
> > >  include/drm/drm_file.h      | 11 +++++++
> > >  3 files changed, 72 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > index cc9acd986c68..01d9e35c0106 100644
> > > --- a/drivers/gpu/drm/drm_auth.c
> > > +++ b/drivers/gpu/drm/drm_auth.c

> > > +static int
> > > +drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> > > +{
> > > +     if (file_priv->pid != task_pid(current) && file_priv->was_master)  
> >
> > Isn't this a typo? Why should we only allow this if the opener is someone
> > else ... that looks like the logind approach? Or is my bolean logic parser
> > broken again.
> >  
> Thanks for spotting it. Indeed that should be:
> 
> if (file_priv->pid == task_pid(current) && file_priv->was_master)
>     return 0;

Hi,

I'm mostly just curious, why is comparing pids safe here? Maybe the
'pid' member is not what userspace calls PID?

What if a malicious process receives a DRM fd from something similar to
logind, then the logind equivalent process dies, and the malicious
process starts forking new processes attempting to hit the same pid the
logind equivalent had, succeeds in that, and passes the DRM fd to that
fork. Is the fork then effectively in control of DRM master?


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Emil Velikov]

On Tue, 11 Feb 2020 at 08:06, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Mon, 10 Feb 2020 19:01:06 +0000
> Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Wed, Feb 05, 2020 at 05:48:39PM +0000, Emil Velikov wrote:
> > > > From: Emil Velikov <emil.velikov@collabora.com>
> > > >
> > > > This commit reworks the permission handling of the two ioctls. In
> > > > particular it enforced the CAP_SYS_ADMIN check only, if:
> > > >  - we're issuing the ioctl from process other than the one which opened
> > > > the node, and
> > > >  - we are, or were master in the past
> > > >
> > > > This allows for any application which cannot rely on systemd-logind
> > > > being present (for whichever reason), to drop it's master capabilities
> > > > (and regain them at later point) w/o being ran as root.
> > > >
> > > > See the comment above drm_master_check_perm() for more details.
> > > >
> > > > Cc: Adam Jackson <ajax@redhat.com>
> > > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> > > > ---
> > > > This effectively supersedes an earlier patch [1] incorporating ajax's
> > > > feedback (from IRC ages ago).
> > > >
> > > > [1] https://patchwork.freedesktop.org/patch/268977/
> > > > ---
> > > >  drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
> > > >  drivers/gpu/drm/drm_ioctl.c |  4 +--
> > > >  include/drm/drm_file.h      | 11 +++++++
> > > >  3 files changed, 72 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > > index cc9acd986c68..01d9e35c0106 100644
> > > > --- a/drivers/gpu/drm/drm_auth.c
> > > > +++ b/drivers/gpu/drm/drm_auth.c
>
> > > > +static int
> > > > +drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> > > > +{
> > > > +     if (file_priv->pid != task_pid(current) && file_priv->was_master)
> > >
> > > Isn't this a typo? Why should we only allow this if the opener is someone
> > > else ... that looks like the logind approach? Or is my bolean logic parser
> > > broken again.
> > >
> > Thanks for spotting it. Indeed that should be:
> >
> > if (file_priv->pid == task_pid(current) && file_priv->was_master)
> >     return 0;
>
> Hi,
>
> I'm mostly just curious, why is comparing pids safe here? Maybe the
> 'pid' member is not what userspace calls PID?
>
PID here is the kernel struct pid. For userspace ones we have the
distinct task_xid_nr, task_xid_vnr and task_xid_nr_ns.
See the documentation [1] for details.

> What if a malicious process receives a DRM fd from something similar to
> logind, then the logind equivalent process dies,
In the logind case, systemd ensures to bring it back up ASAP. For
others - shrug?

> and the malicious
> process starts forking new processes attempting to hit the same pid the
> logind equivalent had, succeeds in that, and passes the DRM fd to that
> fork. Is the fork then effectively in control of DRM master?
>
Valid point, although I believe we're covered.

First and foremost, the pid we store is refcounted [1]. So in order
for this to happen we need have both a) a pretty fundamental refcount
bug for the pid to gets destroyed and b) we need to allocate another
one at the exact same address.

Individually - pretty unlikely, combined - beyond paranoid IMHO.

Additionally, today there are other ways to cause issues. In particular:
 - logind dies
 - the application already has an fd (from logind)
 - the fd is master capable
 - application is free to do as it wishes ... apart from dropping
master (oh noo) and setting it back up again

Or a simple application which loops over open() + drmIsMaster() + close().
There are others, although I'd be going pretty much off-topic.

Thanks
Emil

[1] https://elixir.bootlin.com/linux/v5.5/source/include/linux/sched.h#L1307
[2] https://elixir.bootlin.com/linux/v5.5/source/drivers/gpu/drm/drm_file.c#L127
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Emil Velikov]

On Mon, 10 Feb 2020 at 21:54, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Mon, Feb 10, 2020 at 8:01 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Wed, Feb 05, 2020 at 05:48:39PM +0000, Emil Velikov wrote:
> > > > From: Emil Velikov <emil.velikov@collabora.com>
> > > >
> > > > This commit reworks the permission handling of the two ioctls. In
> > > > particular it enforced the CAP_SYS_ADMIN check only, if:
> > > >  - we're issuing the ioctl from process other than the one which opened
> > > > the node, and
> > > >  - we are, or were master in the past
> > > >
> > > > This allows for any application which cannot rely on systemd-logind
> > > > being present (for whichever reason), to drop it's master capabilities
> > > > (and regain them at later point) w/o being ran as root.
> > > >
> > > > See the comment above drm_master_check_perm() for more details.
> > > >
> > > > Cc: Adam Jackson <ajax@redhat.com>
> > > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> > > > ---
> > > > This effectively supersedes an earlier patch [1] incorporating ajax's
> > > > feedback (from IRC ages ago).
> > > >
> > > > [1] https://patchwork.freedesktop.org/patch/268977/
> > > > ---
> > > >  drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
> > > >  drivers/gpu/drm/drm_ioctl.c |  4 +--
> > > >  include/drm/drm_file.h      | 11 +++++++
> > > >  3 files changed, 72 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > > index cc9acd986c68..01d9e35c0106 100644
> > > > --- a/drivers/gpu/drm/drm_auth.c
> > > > +++ b/drivers/gpu/drm/drm_auth.c
> > > > @@ -135,6 +135,7 @@ static int drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
> > > >               }
> > > >       }
> > > >
> > > > +     fpriv->was_master = (ret == 0);
> > > >       return ret;
> > > >  }
> > > >
> > > > @@ -179,12 +180,64 @@ static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
> > > >       return ret;
> > > >  }
> > > >
> > > > +/*
> > > > + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
> > > > + * CAP_SYS_ADMIN was not set.
> > > > + *
> > > > + * Even though the first client is _always_ master, it also had to be run as
> > > > + * root, otherwise SET/DROP_MASTER would fail. In those cases no other client
> > > > + * could become master ... EVER.
> > > > + *
> > > > + * Resulting in a) the graphics session dying badly or b) a completely locked
> > > > + * session :-\
> > > > + *
> > > > + * As some point systemd-logind was introduced to orchestrate and delegate
> > > > + * master as applicable. It does so by opening the fd and passing it to users
> > > > + * while in itself logind a) set/drop master per users' request and b)
> > > > + * implicitly drops master on VT switch.
> > > > + *
> > > > + * Even though logind looks like the future, there are a few obstacles:
> > > > + *  - using it is not possible on some platforms, or
> > > > + *  - applications may not be updated to use it,
> > > > + *  - any client which fails to drop master* can DoS the application using
> > > > + * logind, to a varying degree.
> > > > + *
> > > > + * * Either due missing root permission or simply not calling DROP_MASTER.
> > > > + *
> > > > + *
> > > > + * Here we implement the next best thing:
> > > > + *   We enforce the CAP_SYS_ADMIN check only if the client was not a master
> > > > + * before. We distinguish between the original master client (say logind) and
> > > > + * another client which has the fd passed (say Xorg) by comparing the pids.
> > > > + *
> > > > + * As a result this fixes, the following when using root-less build w/o logind
> > > > + * - startx - some drivers work fine regardless
> > > > + * - weston
> > > > + * - various compositors based on wlroots
> > > > + */
> > >
> > > I think this breaks logind security. With logind no compositor can open
> > > the device node directly, hence no compositor can accidentally become the
> > > master and block everyone else.
> > >
> > I've explicitly considered this case. AFAICT this patch does not
> > change any of the contract.
> > If you think there's a scenario where things have broken, please let me know.
> >
> > > And for the vt switch logind is the only one that can grant master rights,
> > > and it can make sure that the right compositor gets them. And if the old
> > > compositor is non-cooperating, it can also forcefully remove master
> > > rights.
> > >
> > Yes logind does set/drop master on VT switch, session setup/teardown, etc.
> >
> > To take this a step further, there is no logind API or dbus method for
> > compositors to only set/drop master.
> > Thus logind ensures that compositors are in sane state.
> >
> > > But with this here we lift this restriction if a compositor has ever been
> > > master. So the following thing could happen:
> > > - We have 3 compositors for different users C1, C2, C3
> > > - We switch from C1 to C2
> > > - While we switch no one is master for a moment, which means C3 could
> > >   sneak in and do a quick setmaster, and become master
> > > - Everything would come crashing done since logind believes it already
> > >   revoked master for C1, but somehow it now cant grant master to C2
> > >
> > Does this scenario consider that all three compositors are logind users?
> > If so, C3 should not be able to set or drop master. Since it got its
> > fd from logind:
> >
> >  - `file_priv->pid` will point to systemd-logind, and
> >  - `task_pid(current)` will point to the respective compositor
> >
> > -> EACCES will be returned to any compositor calling drmSetMaster.
> >
> > Regardless of my patch, C3 can open() and simply not release the master.
> > Assuming it's the first DRM client of course - say switch to VTx +
> > login + start C3.
>
> Hm ... I guess this works indeed. Or should. I'm mildly freaked out
> that we're checking for opener_pid == current->pid. Not sure how many
> other security assumptions we're breaking.
>
Today there are many ways to DoS your compositor - regardless if the
app uses logind or not.
As said in the other thread - we do refcount the pid. So its lifetime
should be preserved and the check will be fine.

> > I've been lucky enough to spot various ways to softlock my system...
> > even when the compositor is using logind ;-)
> > If you're really interested I can share, but I'm worried that people
> > may see them as bashing at logind.
> >
> > > I'm not sure we can even support these two models at the same time.
> > >
> > > > +static int
> > > > +drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> > > > +{
> > > > +     if (file_priv->pid != task_pid(current) && file_priv->was_master)
> > >
> > > Isn't this a typo? Why should we only allow this if the opener is someone
> > > else ... that looks like the logind approach? Or is my bolean logic parser
> > > broken again.
> > >
> > Thanks for spotting it. Indeed that should be:
> >
> > if (file_priv->pid == task_pid(current) && file_priv->was_master)
> >     return 0;
> >
> >
> > Modulo any objections, I'll do proper testing and submit a non RFC version.
> > The inline comments will explicitly mention your concerns and why the
> > patch is safe.
>
> Given the above bug I think a solid igt for both the logind and the
> non-logind scenario is needed. We have some helpers to drop root and
> fork stuff and all that, so shouldn't be many lines.

The non-logind case would be pretty trivial. The logind one will take
a bit of time - I need to catch up on all the fancy helpers.

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: rework SET_MASTER and DROP_MASTER perm handling

[Daniel Vetter]

On Tue, Feb 11, 2020 at 11:46:26AM +0000, Emil Velikov wrote:
> On Tue, 11 Feb 2020 at 08:06, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Mon, 10 Feb 2020 19:01:06 +0000
> > Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > > Thanks for having a look Daniel.
> > >
> > > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Wed, Feb 05, 2020 at 05:48:39PM +0000, Emil Velikov wrote:
> > > > > From: Emil Velikov <emil.velikov@collabora.com>
> > > > >
> > > > > This commit reworks the permission handling of the two ioctls. In
> > > > > particular it enforced the CAP_SYS_ADMIN check only, if:
> > > > >  - we're issuing the ioctl from process other than the one which opened
> > > > > the node, and
> > > > >  - we are, or were master in the past
> > > > >
> > > > > This allows for any application which cannot rely on systemd-logind
> > > > > being present (for whichever reason), to drop it's master capabilities
> > > > > (and regain them at later point) w/o being ran as root.
> > > > >
> > > > > See the comment above drm_master_check_perm() for more details.
> > > > >
> > > > > Cc: Adam Jackson <ajax@redhat.com>
> > > > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> > > > > ---
> > > > > This effectively supersedes an earlier patch [1] incorporating ajax's
> > > > > feedback (from IRC ages ago).
> > > > >
> > > > > [1] https://patchwork.freedesktop.org/patch/268977/
> > > > > ---
> > > > >  drivers/gpu/drm/drm_auth.c  | 59 +++++++++++++++++++++++++++++++++++++
> > > > >  drivers/gpu/drm/drm_ioctl.c |  4 +--
> > > > >  include/drm/drm_file.h      | 11 +++++++
> > > > >  3 files changed, 72 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > > > index cc9acd986c68..01d9e35c0106 100644
> > > > > --- a/drivers/gpu/drm/drm_auth.c
> > > > > +++ b/drivers/gpu/drm/drm_auth.c
> >
> > > > > +static int
> > > > > +drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> > > > > +{
> > > > > +     if (file_priv->pid != task_pid(current) && file_priv->was_master)
> > > >
> > > > Isn't this a typo? Why should we only allow this if the opener is someone
> > > > else ... that looks like the logind approach? Or is my bolean logic parser
> > > > broken again.
> > > >
> > > Thanks for spotting it. Indeed that should be:
> > >
> > > if (file_priv->pid == task_pid(current) && file_priv->was_master)
> > >     return 0;
> >
> > Hi,
> >
> > I'm mostly just curious, why is comparing pids safe here? Maybe the
> > 'pid' member is not what userspace calls PID?
> >
> PID here is the kernel struct pid. For userspace ones we have the
> distinct task_xid_nr, task_xid_vnr and task_xid_nr_ns.
> See the documentation [1] for details.
> 
> > What if a malicious process receives a DRM fd from something similar to
> > logind, then the logind equivalent process dies,
> In the logind case, systemd ensures to bring it back up ASAP. For
> others - shrug?
> 
> > and the malicious
> > process starts forking new processes attempting to hit the same pid the
> > logind equivalent had, succeeds in that, and passes the DRM fd to that
> > fork. Is the fork then effectively in control of DRM master?
> >
> Valid point, although I believe we're covered.

Yeah, the kernel-internal pid structure maps to the shiny new pidfd stuff,
not to traditional unix pid numbers with all their problems around races
and reuse when there's not a parent/child relationship.
-Daniel

> 
> First and foremost, the pid we store is refcounted [1]. So in order
> for this to happen we need have both a) a pretty fundamental refcount
> bug for the pid to gets destroyed and b) we need to allocate another
> one at the exact same address.
> 
> Individually - pretty unlikely, combined - beyond paranoid IMHO.
> 
> Additionally, today there are other ways to cause issues. In particular:
>  - logind dies
>  - the application already has an fd (from logind)
>  - the fd is master capable
>  - application is free to do as it wishes ... apart from dropping
> master (oh noo) and setting it back up again
> 
> Or a simple application which loops over open() + drmIsMaster() + close().
> There are others, although I'd be going pretty much off-topic.
> 
> Thanks
> Emil
> 
> [1] https://elixir.bootlin.com/linux/v5.5/source/include/linux/sched.h#L1307
> [2] https://elixir.bootlin.com/linux/v5.5/source/drivers/gpu/drm/drm_file.c#L127

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel