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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Dec 2007 12:40:53 -0500
From:	Loic Prylli <loic@...i.com>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Daniel Barkalow <barkalow@...ervon.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kai Ruhnau <kai@...getaschen.dyndns.org>,
	Robert Hancock <hancockr@...w.ca>,
	Jeff Garzik <jeff@...zik.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	gregkh@...e.de, linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Martin Mares <mj@....cz>, Matthew Wilcox <matthew@....cx>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
 opt-in



On 12/28/2007 11:38 AM, Ivan Kokshaysky wrote:
> On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote:
>   
>> it removes code by removing quirks / known not working stuff..
>>     
>
>   




The only quirk I see removed is a bitmap with an arbitrary size (that we
don't really know is sufficient for every system), and that is only
built using comparison between mmconf and type1 accesses.  IMHO, there
is zero knowledge in that removed code (no knowledge about specific
chipsets that work or don't work, or misleading BIOSes).




> This not working stuff gets detected at probe time - see
> drivers/pci/probe.c:pci_cfg_space_size().
>   


This indeed avoids most mmconf invalid attempts (for extended-conf-space
probing that goes through pci_find_ext_capability() or from user-space).


One could think of adding a cfg_size check in
pci_read_config_{read/write), but IMHO that would be useless, since
direct read/write into a known extended-conf-space register in the
extended-config-space can only happen for a pci-express device, and
there is ample evidence that such accesses always work (more exactly
MCFG can always be trusted for pcie devices).

One thing that could be changed in pci_cfg_space_size() is to avoid
making a special case for PCI-X 266MHz/533Mhz (assume cfg_size == 256
for such devices too, reserve extended cfg-space for pci-express
devices). There is good reasons to think no such PCI-X 266Mhz/533 device
will ever have an extended-space (no capability IDs was ever defined in
the PCI-X 2.0 spec, no new revision is planned). Such a check would
avoid the possibility of trying extended-conf-space access for PCI-X 2.0
devices behind a amd-8132 or similar (such accesses would just returnd
-1, but there was some objections raised about doing anything like that
other than at initialization time, even if there is ample reasons to
argue it would be harmless).


Loic


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