linux-kernel - Re: iwlagn: memory corruption with WPA enterprise

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Nov 2011 14:05:28 +0100
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Tomáš Janoušek <tomi@...i.cz>
Cc:	linux-kernel@...r.kernel.org, Wey-Yi Guy <wey-yi.w.guy@...el.com>,
	linux-wireless@...r.kernel.org
Subject: Re: iwlagn: memory corruption with WPA enterprise

Hi Tomáš

On Sat, Nov 19, 2011 at 07:11:06PM +0100, Tomáš Janoušek wrote:
> On Mon, Nov 14, 2011 at 03:07:15PM +0100, Stanislaw Gruszka wrote:
> > On Fri, Nov 11, 2011 at 04:01:05PM +0100, Tomáš Janoušek wrote:
> > > Could you please elaborate on that thing with enabling IOMMU? The only thing I
> > > know about IOMMU is that it is somehow related to VT-d (passing whole PCI
> > > devices to virtual guests), and that I have to pass intel_iommu=off to kernel
> > > command line, otherwise the machine doesn't even boot. Is that a problem?
> > Yes. That mean iommu software or hardware is broken on your system.
> >
> > I have no other ideas how to track this down. I think now, this is
> > a firwmare issue. BTW, you suspected that from very beginning :-)
> > This could be also a driver issue, but AFAICT programing DMA do not
> > differ on 6205 from other devices, so bug in firmware is much more
> > probable reason of corruption.
> 
> I have some news. I got IOMMU to work, because I identified the problem [1]
> and disabled firewire-ohci for the time being completely, but I'm not sure
> what do I need to do to make it catch the problem. I assumed that all I need
> is to intel_iommu=on and then all devices do DMA stuff in isolation, but I can
> still reproduce the issue without the smallest hint of an error in dmesg. Does
> it tell us anything, or shall I enable some more debugging stuff?
> 
> [1] http://thread.gmane.org/gmane.linux.kernel.pci/8765/focus=1217800

The farther we get the problem is more and more strange.

Device that write to wrong address, would generate:

DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000
DMAR:[fault reason 05] PTE Write access is not set

But only if

PCI-DMA: Using DMAR IOMMU

was printed in dmesg before. DMAR can be disabled by graphics
driver, or maybe by other drivers too. Then above print will
be missed in dmesg and protection would not work.

Try "dmesg | grep DMAR" to see if DMA remapping is really is
in use. 

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