lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-Id: <1303820801-3841-1-git-send-email-stefan.bader@canonical.com>
Date:	Tue, 26 Apr 2011 14:26:41 +0200
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Jan Niehusmann <jan@...dor.com>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	Ben Hutchings <ben@...adent.org.uk>,
	Stefan Bader <stefan.bader@...onical.com>,
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: [2.6.32+drm33-longterm] Patch "Subject: [PATCH 15/21] drm/i915: fix memory corruption with GM965 and >4GB RAM" has been added to staging queue

This is a note to let you know that I have just added a patch titled

    Subject: [PATCH 15/21] drm/i915: fix memory corruption with GM965 and >4GB RAM

to the drm-next branch of the 2.6.32+drm33-longterm tree which can be found at

  http://git.kernel.org/?p=linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git;a=shortlog;h=refs/heads/drm-next

If you, or anyone else, feels it should not be added to the drm33-longterm tree,
please reply to this email not later than 8 days after this email was sent.

Thanks.
-Stefan

------

>From 80b161cb0bac6dc7644776615f1cea3074b1e788 Mon Sep 17 00:00:00 2001
From: Jan Niehusmann <jan@...dor.com>
Date: Fri, 4 Mar 2011 00:28:02 +0100
Subject: [PATCH 15/21] drm/i915: fix memory corruption with GM965 and >4GB RAM

commit 6927faf30920b8c03dfa007e732642a1f1f20089 upstream.

On a Thinkpad x61s, I noticed some memory corruption when
plugging/unplugging the external VGA connection. The symptoms are that
4 bytes at the beginning of a page get overwritten by zeroes.
The address of the corruption varies when rebooting the machine, but
stays constant while it's running (so it's possible to repeatedly write
some data and then corrupt it again by plugging the cable).

Further investigation revealed that the corrupted address is
(dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
the hardware status page of the i965 graphics card, cut to 32 bits.

So it seems that for some memory access, the hardware uses only 32 bit
addressing. If the hardware status page is located >4GB, this
corrupts unrelated memory.

Signed-off-by: Jan Niehusmann <jan@...dor.com>
Acked-by: Daniel Vetter <daniel.vetter@...ll.ch>
Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
[bwh: Backport to 2.6.33]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
Signed-off-by: Stefan Bader <stefan.bader@...onical.com>
---
 drivers/gpu/drm/i915/i915_dma.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c93c98a..be27acc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1411,6 +1411,17 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	if (IS_GEN2(dev))
 		pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(30));

+	/* 965GM sometimes incorrectly writes to hardware status page (HWS)
+	 * using 32bit addressing, overwriting memory if HWS is located
+	 * above 4GB.
+	 *
+	 * The documentation also mentions an issue with undefined
+	 * behaviour if any general state is accessed within a page above 4GB,
+	 * which also needs to be handled carefully.
+	 */
+	if (IS_I965G(dev) && !IS_G4X(dev) && !IS_IRONLAKE(dev))
+		pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(32));
+
 	dev_priv->regs = ioremap(base, size);
 	if (!dev_priv->regs) {
 		DRM_ERROR("failed to map registers\n");
--
1.7.0.4

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ