linux-kernel - Re: hpsa driver bug crack kernel down!

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]

Message-ID: <1397119587.19944.14.camel@shinybook.infradead.org>
Date:	Thu, 10 Apr 2014 08:46:28 +0000
From:	"Woodhouse, David" <david.woodhouse@...el.com>
To:	"joro@...tes.org" <joro@...tes.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"bhe@...hat.com" <bhe@...hat.com>,
	"jiang.liu@...ux.intel.com" <jiang.liu@...ux.intel.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"James.Bottomley@...senpartnership.com" 
	<James.Bottomley@...senpartnership.com>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"scameron@...rdog.cce.hp.com" <scameron@...rdog.cce.hp.com>,
	"davidlohr@...com" <davidlohr@...com>
Subject: Re: hpsa driver bug crack kernel down!

On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
> [+ David, VT-d maintainer ]
> 
> Jiang, David, can you please have a look into this issue?
> 

> > > >> > > > > DMAR:[fault reason 02] Present bit in context entry is clear
> > > >> > > > > dmar: DRHD: handling fault status reg 602
> > > >> > > > > dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000

That "Present bit in context entry is clear" fault means that we have
not set up *any* mappings for this PCI device… on this IOMMU.

> > Yes, specifically (finally done bisecting):
> > 
> > commit 2e45528930388658603ea24d49cf52867b928d3e
> > Author: Jiang Liu <jiang.liu@...ux.intel.com>
> > Date:   Wed Feb 19 14:07:36 2014 +0800
> > 
> >     iommu/vt-d: Unify the way to process DMAR device scope array

This commit is about how we decide which IOMMU a given PCI device is
attached to.

Thus, my first guess would be that we are quite happily setting up the
requested DMA maps on the *wrong* IOMMU, and then taking faults when the
device actually tries to do DMA.

However, I'm not 100% convinced of that. The fault address looks
suspiciously like a true physical address, not a virtual bus address of
the type that we'd normally allocate for a dma_map_* operation. Those
would start at 0xfffff000 and work downwards, typically.

Do you have 'iommu=pt' on the kernel command line? Can I see the full
dmesg as this system boots, and also a copy of the DMAR table?

We should also rate-limit DMA faults, which would avoid the lockup
failure mode. Bjorn, what should an IOMMU driver *do* when it detects
that a device is creating an endless stream of DMA faults and isn't
aborting the transaction?

I can set it to silent so that it just stops *reporting* the DMA faults
for that device... and I suppose I can re-enable them when I next see a
DMA mapping for it (although actually it'd be better to have a hook to
do that on FLR or something like that). But there must be a better
answer than that, surely? And I don't want to hack it up locally in
*one* specific IOMMU driver, any more than I have to.

On a POWER system with EEH, the kernel would end up isolating the
offending device completely, and subsequently resetting it...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (3437 bytes)