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]

Message-Id: <200801302151.12544.jbarnes@virtuousgeek.org>
Date:	Wed, 30 Jan 2008 21:51:12 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Greg KH <greg@...ah.com>
Cc:	Matthew Wilcox <matthew@....cx>,
	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 Tuesday 29 January 2008 05:19:55 am Greg KH wrote:
> Hahahaha, oh, that's a good one...
>
> But what about the thousands of implementations out there that are
> buggy?
>
> I'm with Arjan here, I'm very skeptical.

Ugg, let's look at the actual data (again); I'm really not sure why people 
are jumping to such dire conclusions about the current state of things.

AIUI we only have 3 issues so far (remember mmconfig has been enabled in -mm 
for a long time):
  1) host bridge decode problems (disabling decode to avoid overlaps can 
cause some bridges to stop decoding RAM addrs, but we have a fix for that)
  2) config space retry on ATI (I think willy already debunked this one?)
  3) some FUD about SMM or other firmware interrupts coming in during BAR 
sizing while decode is disabled (this one is just pure FUD; if we want to 
solve it properly we need a new platform hook to disable SMM/NMI/etc. 
around PCI probing)

What else was there?  What reason do we have to think that things are so 
disastrous?

So I really prefer willy's approach to Arjan's alternative...

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