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: <476DBB18.1090407@garzik.org>
Date:	Sat, 22 Dec 2007 20:34:16 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	linux-kernel@...r.kernel.org, gregkh@...e.de,
	linux-pci@...ey.karlin.mff.cuni.cz, torvalds@...ux-foundation.org
Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a driver
 opt-in issue

Arjan van de Ven wrote:
> On Sat, 22 Dec 2007 09:20:06 -0500
> Jeff Garzik <jeff@...zik.org> wrote:
> 
>> Arjan van de Ven wrote:
>>> Hi,
>>>
>>> Linus really wants the extended (4Kb) PCI configuration space
>>> (using MCFG acpi table etc) to be opt-in, since there's many issues
>>> with it and most drivers don't even use/need it. The idea behind
>>> opt-in is that if you don't use it, you don't get to suffer the
>>> bugs...
>>>
>>> Booted on my 64 bit test machine; sadly it has a defunct BIOS that
>>> doesn't have a working MCFG.
>>>
>>>
>>> From: Arjan van de Ven <arjan@...ux.intel.com>
>>> Subject: Make MMCONFIG space a driver opt-in
>>>
>>> There are many issues with using the extended PCI configuration
>>> space (CPU, Chipset and most of all BIOS bugs). This while the vast
>>> majority of drivers and devices don't even use/need to use the
>>> memory mapped access methods since they don't use the config space
>>> beyond the traditional 256 bytes.
>>>
>>> This patch makes accessing the extended config space a driver
>>> choice, via the
>>>
>>> pci_enable_ext_config(pdev)
>> Yuck.  And, Linus is just being silly.  Wait a year then turn on 
>> MMCONFIG :)  It took PCI MSI a while to mature, but is finally
>> getting there.
>>
> 
> Do you hate the name or the concept? I'm certainly open for a better name.... 

Many problems:

* even if driver not loaded, you might need to access extended capabilities

* kernel hacker (me!) might request user to dump PCI config space to see 
what changes, after various experiments.  we need to see that extended 
space, if it exists, even if driver not loaded.

* this "mixed config access" model is new to Linux, after always having 
config access type be a global system attribute.  It introduces new 
complexity and new inconsistency all over the place.

* hardware makers will not test this weird "mixed access" model.

You thought mmconfig was poorly tested?  Well, why the hell choose 
something with even less testing behind it (and future likelihood of nil 
testing).

Always-off is better than mixed access.

	Jeff


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ