linux-kernel - Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

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:	Tue, 29 Jan 2008 20:45:55 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Greg KH <greg@...ah.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Tony Camuso <tcamuso@...hat.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Loic Prylli <loic@...i.com>, Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Jeff Garzik <jeff@...zik.org>,
	linux-pci@...ey.karlin.mff.cuni.cz, Martin Mares <mj@....cz>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
> On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
> > I'm more optimistic because we've so severely restricted the use of
> > mmconf after these patches that it's unlikely to cause problems.  I also
> > hear Vista is now using mmconf, so fewer implementations are going to
> > be buggy at this point.
> 
> Hahahaha, oh, that's a good one...

Thanks Greg.  What happened to "Can't we all try to get along"?

> But what about the thousands of implementations out there that are
> buggy?
> 
> I'm with Arjan here, I'm very skeptical.

Maybe I'm insufficiently imaginative.  Can you come up with a plausible
way in which the two patches I posted will succumb to bugs?  After those
patches we only use mmconf if:

 1. conf1 has failed to work
OR
 2. user has compiled their own kernel without support for conf1
OR
 3. kernel probes config space 0x100 to see if it can access extended
    config space (requires the device to be PCIe or PCI-X2)
OR
 4. root attempts to lspci -xxxx or lspci -v
OR
 5. device driver tries to access extended config space

With Arjan's patch, I believe only case 3 changes.  In cases 4 and 5,
either lspci or the device driver will jump through the hoop to enable
access to extended config space.

> Matthew, with Arjan's patch, is anything that currently works now
> broken?  Why do you feel it is somehow "wrong"?

lspci is broken.  It used to be able to access extended config space, and
now can't unless it is patched to know about the sysfs flag to enable it.

If you're determined to implement something to disable extended config
space by default, it can be done in a much better way than Arjan's patch
-- less code (both source and object).

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/