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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LFD.0.9999.0712222109560.21557@woody.linux-foundation.org>
Date:	Sat, 22 Dec 2007 21:18:25 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	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, 23 Dec 2007, Jeff Garzik wrote:
> 
> Then let's do it right:  disable mmconfig by default on x86, and enable it
> when passed "pci=mmconfig".

I'm certainly ok with that, but then you say:

> > And yes, if you want the capability following to notice automatically when
> > capabilities really do go into the 0x100+ range, that's fine. I suspect 
> 
> Yes, we /must/ do this checking, if we don't already.

Hell no. If the user asked for mmconfig to be disabled, it needs to be 
disabled, because it may well be broken and non-working. It's better to 
not see some capabilities than to lock up the machine.

So what is it? Is it "some machines do it automatically when needed" or is 
it "always disabled"?

You seem to now say that "always disabled by default" isn't good either.

What do I need to do to convince you that the *right* thing to do is:

 - disabled by default, unless user *explicitly* asks for it with 
   "pci=mmconfig"

 - but certain events will enable it automatically, unless the user 
   *explicitly* said (or we had a quirk that explicitly disabled it) 
   something like pci=mmconfig

See what I'm saying? You don't really seem to be disagreeing. It seems to 
be, in fact, exactly what you want.

I'm saying that yes, the PCI capability code might be one such "enable 
mmconfig if not explicitly disabled" user.

But I also suspect that some drivers might want to do it, and I'm almost 
certain that some DMI quirks will want to do it (ie "I recognize this 
machine, and this machine is from 2011, and wants MMCONFIG"). So we need 
to have an interface for those quirks or other events to also do it, it 
cannot be just a "PCI capabilities do it".

Quite frankly, the fewer drivers that do it, the happier I am. Maybe *no* 
drivers will do it. If so, "Hallelujah, brother, give me an Amen!". But we 
clearly want an interface for _some_ things to say "we might want to have 
mmconfig". Maybe it's only PCI capabilities. 

Regardless. Even if *no* driver ever does it, the logical interface will 
clearly be "pci_enable_mmio(pdev)".

You can then argue all you want against individual drivers actually ever 
using it, and I'll support you on that. I think MMCONFIG was/is a total 
waste of everybodys time.

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