All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Antoine, Peter" <peter.antoine@intel.com>
To: "chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "airlied@redhat.com" <airlied@redhat.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH 1/5] drm: Kernel Crash in drm_unlock
Date: Fri, 24 Apr 2015 05:52:40 +0000	[thread overview]
Message-ID: <1429854756.30618.15.camel@peterant-linux> (raw)
In-Reply-To: <20150423143916.GK21511@nuc-i3427.alporthouse.com>

I picked up this work due to the following Jira ticket created by the
security team (on Android) and was asked to give it a second look and
found a few more issues with the hw lock code.

https://jira01.devtools.intel.com/browse/GMINL-5388
I/O control on /dev/dri/card0 crashes the kernel (0x4008642b)

It also stops Linux as it kills the driver, I guess it might be possible
to reload the gfx driver. On a unpatched system the test that is
included in the issue or the igt test that has been posted for the issue
will show the problem.

I ran the test on an unpatched system here and the gui stopped and the
keyboard stopped responding, so I rebooted. With the patched system I
did not need to reboot.

Should I change the SIGTERM to SIGSEGV, not quite the same thing but
tooling is better at handling a segfault than a SIGTERM and the
application that calls this IOCTL is using an uninitialised hw lock so
it is kind of the same as differencing an uninitialised pointer (kind
of). Or, I could just remove it, but the bug has been in the code for at
least two years (and known about), and I would guess that any code that
is calling this is fuzzing the IOCTLs (as this is how the security team
found it) and we should reward them with a application exit.

Peter. 


On Thu, 2015-04-23 at 15:39 +0100, Chris Wilson wrote:
> On Thu, Apr 23, 2015 at 02:34:24PM +0000, Antoine, Peter wrote:
> > Before the patch the system required rebooting (driver crash and/or kernel panic).
> > Now the application gets terminated.
> 
> It should have an GPF which should not have required a reboot, but
> terminated the application. Unless you set it to automatically reboot.
> -Chris
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-04-24  5:52 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 [this message]
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ä
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=1429854756.30618.15.camel@peterant-linux \
    --to=peter.antoine@intel.com \
    --cc=airlied@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.