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

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]

Message-ID: <20071223110337.GA25441@jurassic.park.msu.ru>
Date:	Sun, 23 Dec 2007 14:03:37 +0300
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Loic Prylli <loic@...i.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de,
	linux-pci@...ey.karlin.mff.cuni.cz,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a
	driver opt-in issue

On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
> Failures are more predictable and more consistent with an all-or-none 
> scenario.  The all-or-none solutions are the least complex on the software 
> side, and far more widely tested than any mixed config access scheme.

Nope. The vast majority of mmconfig problems that happen at boot time
actually have nothing to do with "broken" or "working" mmconfig.
Typically these are
- mmconf area overlapped during BAR sizing;
- BIOS (or kernel) placed some MMIO in the middle of mmconfig area,
  which looks like some random device "doesn't like mmconfig".

This is a result of all-or-none approach, as mmconfig is fundamentally
unsafe until after PCI init is done.

The mixed access that Loic proposes allows to avoid these boot problems
just for free. Systems that have both non-mmconf PCI(X) and mmconf PCI-E
domains could be handled almost for free as well.
And probably most important thing is that the x86 pci_conf implementation
would be so much simpler and cleaner that I honestly don't understand
why are we still discussing it ;-)

At the same time, making drivers to request extended config space
still makes sense. I think of pci_request_ext_conf(dev, drv_name) which
doesn't set any per-device flag, but
- returns success or failure depending on mmconf availability;
- can be logged by kernel to make it easier to debug if something
  goes wrong.

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