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]

Date:	Mon, 24 Dec 2007 14:22:46 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Loic Prylli <loic@...i.com>,
	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 Mon, Dec 24, 2007 at 10:51:22AM -0800, Linus Torvalds wrote:
> The *second* problem is entirely a kernel internal issue. It's the one 
> that causes us the biggest issues right now, but it's also the one that 
> will not impact user space at all once if is fixed. So once we do the 
> *early* probing using anything but mmconfig accesses, we can then much 
> more easily enable mmconfig later, and by the time the user does anything 
> like "lspci -vvvxxxx", we could do those mmconfig accesses.

I had a nice idea to fix this ... will post a patch to do that later.

> I also suspect that we *may* want to use a separate file for the extended 
> config. Right now, things like lspci read the config space by accessing 
> a file like
> 
> 	/sys/bus/pci/devices/0000:00:00.0/config
> 
> and I'm not at all sure we want to extend that one past the first 256 
> bytes of config space. Why? Because I don't want old programs that may not 
> know how dangerous the rest of the space is to read extended config space 
> by mistake when they don't know how to parse it anyway.

Unless we're talking about crazy, crazy programs that blindly open and
read every file in sysfs as root (yes, they exist, and they already cause
problems simply by reading past the first 64 bytes of config space which
causes problems for, eg, sym53c875 cards), non-root accesses are already
restricted to the first 64 bytes, so it's no more of a problem than it
currently is.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/