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: <20071224040007.1277fddd@laptopd505.fenrus.org>
Date:	Mon, 24 Dec 2007 04:00:07 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.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, 24 Dec 2007 06:54:30 -0500
Jeff Garzik <jeff@...zik.org> wrote:

> Arjan van de Ven wrote:
> > I can see the point of having a sysfs attribute to enable MMCONF
> > from userspace, so that userland diagnostics tools can turn it on
> > if they really really want to. (I'd make that printk a nice warning
> > "application XYZ is enabling extended config space for devize ABC"
> > so that if the box then crashes and burns, people know who/why and
> > where to direct their emails ;-)
> > 
> > We did something similar for "enable", it's maybe 10 lines of code
> > or so.
> > 
> > I would assume lspci and friends would then only turn that on at
> > explicit admin request
> 
> Absolutely...  I'm not asking to default it on, just asking for it to
> be possible :)
> 

ok so to summarize things a bit (I'll admit bias here but still ;)

1) having a per driver function to say "I'd like extended config space" is ok
   (it's the driver that knows what is needed after all)
2) we need a way for userspace to do the same for a given device
   (which then will print a nice warning who does what to whom)
3) we need to have the "no extended config space unless someone wants it" behavior
4) It's inevitable that this will end up being per device given that we'll end up with
   per device "this one is b0rked" quirks over time (even shortly)
5) architectures that have sane extended config space access should just be able to provide
   it always. This could even be on x86 based on BIOS date (say 2009 :)

the patch I posted does 1) 3) 4) and the first half of 5)
I'll update the patch to do 2) and the rest of 5)

Is there anything I skipped in the summary above?
(and yes I realize this needs lspci to be expanded some to set the flag if the admin really asks for it, 
but such is life)

-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/