linux-kernel - Re: [PATCH] Disable Bus Master on PCI device shutdown

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

Message-ID: <1339091024.25761.896.camel@lyra>
Date:	Thu, 07 Jun 2012 11:43:44 -0600
From:	Khalid Aziz <khalid.aziz@...com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, bhelgaas@...gle.com,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH] Disable Bus Master on PCI device shutdown

On Wed, 2012-06-06 at 21:09 +0100, Matthew Garrett wrote:
> On Wed, Jun 06, 2012 at 12:42:07PM -0700, Eric W. Biederman wrote:
> 
> > pci_device_shutdown calls drv->shutdown before calling
> > pci_device_disable.  Which means that only devices that have trouble
> > with this bit being flipped while DMA is ongoing and don't bother
> > to stop their own DMA will have a problem.
> 
> drv->shutdown should already be quiescing the hardware. If it isn't, it 
> should be. If it is, what does this patch fix? Many drivers 
> call pci_enable_device() early enough that they clearly expect the 
> hardware to be quiescent when they do so, so this really does seem to 
> simply handle the kexec case without handling any other cases that could 
> be similarly problematic.                               
> 

I agree drv->shutdown should quiesce the hardware (although anecdotal
evidence suggests that is not happening), so turning Bus Master bit off
is an additional safety measure. As Alan pointed out, doing that can be
fraught with danger. Clearing Bus Master bit seems like the right thing
to do, but due to buggy hardware/firmware it can cause problems,
although those problems happen at predictable times and thus become
easier to diagnose.

I am considering other options. Andi mentioned command line option which
does allow for some control instead of blindly clearing Bus Master bit
on all system. I am also wondering if clearing Bus Master bit on just
the PCI bridges is an option. If Bus Master bit is clear on a bridge, it
is not supposed to allow DMA transactions through it. That can prevent
random memory corruption by broken devices and also not upset the
devices that do not like their Bus Master bit cleared. Any opinions on
this option?

I have also acquired a broadcom NIC that is causing what looks like
random DMAs into kernel memory on a kexec, although this is with a
kernel that does not have the Bus Master reset patch. I will run some
experiments on this NIC and see what I can figure out.

====================================================================
Khalid Aziz                                         Unix Systems Lab
(970)898-9214                                        Hewlett-Packard
khalid.aziz@...com                                  Fort Collins, CO

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