linux-kernel - Re: [RFC/PATCH]] x86: pci: Disable IO/Mem on a device when resources can't be allocated

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: <20071219134350.GA19698@jurassic.park.msu.ru>
Date:	Wed, 19 Dec 2007 16:43:50 +0300
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Johannes Weiner <hannes@...urebad.de>,
	linux-pci@...ey.karlin.mff.cuni.cz, Alan Cox <alan@...hat.com>,
	Greg Kroah-Hartman <greg@...ah.com>, jgarzik@...ox.com,
	wingel@...o-system.com,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	james.smart@...lex.com, linux-driver@...gic.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH]] x86: pci: Disable IO/Mem on a device when
	resources can't be allocated

On Wed, Dec 19, 2007 at 04:10:19PM +1100, Benjamin Herrenschmidt wrote:
> This patch changes the x86 PCI code to disable IO and/or Memory
> decoding on a PCI device when a resource of that type failed to
> be allocated.

Oh, this opens up a can of worms ;-)

In ideal world, the patch would be perfectly valid. But on x86 we have
at least two firmware layers (E820 and ACPI), each with its own (often
totally crazy) view on system resources. OTOH, we cannot completely ignore
the firmware - otherwise the resource allocator could step onto some
hidden/undocumented system decode ranges...
One of the typical reasons for "dangling BAR" on x86 is that a resource
allocation failed because BIOS has reserved address region for the
very same BAR ;-)

Perhaps you've seen most recent illustration of x86 resource allocation
problems:
 http://lkml.org/lkml/2007/12/17/429

Plus there are lots of x86 hardware like host bridges with a BAR
representing the system RAM, IOAPIC BARs with some high order bits
hardwired to "1" and so on. Which also doesn't make life any easier.

That's why I still think that res->parent check is not enough for
x86 and we need some resource flag that tells generic PCI code
"We failed to allocate this resource, but please don't touch it!".
Some code is already using IORESOURCE_PCI_FIXED for that purpose, so it
would suffice.
On the other hand, with that flag we can move all those horrible
exceptions like PCI_CLASS_BRIDGE_HOST (which nearly breaks alpha, BTW)
and PCI_CLASS_SYSTEM_PIC from generic code to arch/x86 where it belongs.

> I'll wait for more comments today and post the whole 5 again tomorrow
> as official candidates for inclusion :-) (BTW. What is people general
> feeling about inline vs. non inline for the functions in pci.c ?)

I think inlines are prettier, but not allowing direct use of the _flag
function is a valid argument too. So I'm fine with both.

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/