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

Message-id: <478BF76F.8080702@shaw.ca>
Date:	Mon, 14 Jan 2008 17:59:43 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	tcamuso@...hat.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Greg KH <greg@...ah.com>, Matthew Wilcox <matthew@....cx>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Jeff Garzik <jeff@...zik.org>,
	linux-pci@...ey.karlin.mff.cuni.cz,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Martin Mares <mj@....cz>, Loic Prylli <loic@...i.com>,
	Prarit Bhargava <prarit@...hat.com>,
	"Chumbalkar, Nagananda" <Nagananda.Chumbalkar@...com>,
	"Schoeller, Patrick (Linux - Houston, TX)" <Patrick.Schoeller@...com>,
	Bhavana Nagendra <bnagendr@...hat.com>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
 opt-in

Arjan van de Ven wrote:
> On Sun, 13 Jan 2008 22:29:23 -0500
> Tony Camuso <tcamuso@...hat.com> wrote:
> 
>> . There is no need to provide different PCI config access
>>    mechanisms at device granularity, since the PCI config access
>>    mechanism between the CPU and the Northbridge is opaque to
>>    the devices. PCI config mechanisms only need to differ at
>>    the Northbridge level.
> 
> This ignores the "lets make it not matter for the 99% of the users" case.
>> . If the system is capable of conf1, then PCI config access
>>    at offsets < 256 should be confined to conf1. This solution
>>    is most effective for existing and legacy systems.
> 
> not "conf1" but "what the platform thinks is the best method for < 256".
> 
> We have this nice abstraction for the platform to select the best method... we should use it.
> 
> And still, it's another attempt to get this fixed (well.. it's been 2 years in the coming so far, maybe this will
> be the last one, maybe it will not be... we'll see I suppose, but it sucks to be a user who doesn't 
> need any of the functionality that the extended config space provides in theory but gets to suffer more of the issues)

There actually haven't been that many attempts to "get this fixed". It's 
been more a) people complaining about it and nothing being done about 
the problems and b) adding hacks to blindly disable it because of 
reported problems without root-causing why those problems were showing 
up. With such approaches no wonder it has not been reliable to try  and 
use MMCONFIG in the past..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

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