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: <20071224212246.GF1695@parisc-linux.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ