public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: daniel.vetter@ffwll.ch, Peter Antoine <peter.antoine@intel.com>,
	intel-gfx@lists.freedesktop.org,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 2/2] drm: Make Legacy Context access functions optional.
Date: Wed, 13 May 2015 12:41:31 +0300	[thread overview]
Message-ID: <20150513094131.GR18908@intel.com> (raw)
In-Reply-To: <20150513071909.GS15256@phenom.ffwll.local>

On Wed, May 13, 2015 at 09:19:09AM +0200, Daniel Vetter wrote:
> On Wed, May 13, 2015 at 07:54:48AM +0100, Peter Antoine wrote:
> > As these functions are only used by one driver and there are security holes
> > in these functions. Make the functions optional.
> > 
> > These changes are based on the two patches:
> >   commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
> >   Author: Dave Airlie <airlied@redhat.com>
> > 
> > And the commit that the above patch reverts:
> >   commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
> >   Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > 
> > This should now turn off the context feature.
> > 
> > Issue: VIZ-5485
> > Signed-off-by: Peter Antoine <peter.antoine@intel.com>
> 
> Please cc drm core patches to dri-devel. Review below.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_context.c | 36 ++++++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/drm_drv.c     | 12 +++++++-----
> >  2 files changed, 43 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
> > index 9b23525..574be2a 100644
> > --- a/drivers/gpu/drm/drm_context.c
> > +++ b/drivers/gpu/drm/drm_context.c
> > @@ -53,6 +53,9 @@ struct drm_ctx_list {
> >   */
> >  void drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
> >  {
> > +	if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
> > +		return -EINVAL;
> 
> This doesn't compile too well. Also like with the previous patch, drivers
> without DRIVER_MODESET still need these ioctls.

Only via actually needs them AFAIK, but continuing to allow them for the
rest of the old drivers is no worse than what we have today.

And I think nouveau just needs a nop create/destroy ioctls, so I think
we should really just make those two nops for nouveau (or maybe for all
modern drivers?) and reject the rest of the ioctls even for nouveau.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-05-13  9:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-23 14:07 [PATCH 0/5] HW_LOCK Security Patches Peter Antoine
2015-04-23 14:07 ` [PATCH 1/5] drm: Kernel Crash in drm_unlock Peter Antoine
2015-04-23 14:19   ` [Intel-gfx] " Chris Wilson
2015-04-23 14:34     ` Antoine, Peter
2015-04-23 14:39       ` [Intel-gfx] " Chris Wilson
2015-04-24  5:52         ` Antoine, Peter
2015-04-28  9:21           ` Dave Gordon
2015-04-28  9:52             ` chris
2015-05-04 13:52               ` Daniel Vetter
2015-05-05  6:37                 ` Antoine, Peter
2015-05-05  7:20                   ` Daniel Vetter
2015-04-28 14:56             ` Dave Gordon
2015-04-23 14:07 ` [PATCH 2/5] drm: Fixes unsafe deference in locks Peter Antoine
2015-04-23 14:21   ` [Intel-gfx] " Chris Wilson
2015-04-23 14:07 ` [PATCH 3/5] drm: Possible lock priority escalation Peter Antoine
2015-04-27 16:52   ` [Intel-gfx] " Ville Syrjälä
2015-05-04 13:56     ` Daniel Vetter
2015-05-05  6:45       ` Antoine, Peter
2015-05-05  7:23         ` [Intel-gfx] " Daniel Vetter
2015-04-23 14:07 ` [PATCH 4/5] drm: Make HW_LOCK access functions optional Peter Antoine
2015-04-27 17:03   ` Ville Syrjälä
2015-04-28  5:52     ` Antoine, Peter
2015-04-28 10:40       ` Ville Syrjälä
2015-04-28 11:29         ` Antoine, Peter
2015-04-28 13:08           ` Ville Syrjälä
2015-04-28 13:29             ` Antoine, Peter
2015-05-04 14:05               ` Daniel Vetter
2015-05-04 23:02                 ` Dave Airlie
2015-04-23 14:07 ` [PATCH 5/5] drm: Make Legacy Context " Peter Antoine
2015-04-23 19:01   ` shuang.he
2015-05-13  6:54 ` [PATCH v2 0/2] HW_LOCK kernel patched Peter Antoine
2015-05-13  6:54   ` [PATCH v2 1/2] drm: Make HW_LOCK access functions optional Peter Antoine
2015-05-13  7:14     ` Daniel Vetter
2015-05-13  7:24       ` Daniel Vetter
2015-05-13  6:54   ` [PATCH v2 2/2] drm: Make Legacy Context " Peter Antoine
2015-05-13  7:19     ` Daniel Vetter
2015-05-13  9:41       ` Ville Syrjälä [this message]
2015-05-15  5:58     ` shuang.he
2015-05-13  7:08   ` [PATCH v2 0/2] HW_LOCK kernel patched Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150513094131.GR18908@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=peter.antoine@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox