linux-kernel - Re: [PATCH 3/3] PCI: allocate bus resources from the top down

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: <4C915AB2.9090203@zytor.com>
Date:	Wed, 15 Sep 2010 16:45:54 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Brian Bloniarz <phunge0@...mail.com>,
	Charles Butterfield <charles.butterfield@...tcentury.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	Stefan Becker <chemobejk@...il.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 3/3] PCI: allocate bus resources from the top down

On 09/15/2010 03:44 PM, Bjorn Helgaas wrote:
> 
> I'd like to do that, but I don't see a good way to do it yet.
> 
> We saw the problem on a T3500, a T3400, and a T4500, and I'm sure there
> are others.  So I don't know how to identify the affected machines.
> 
> And I don't know how to identify the invalid ranges, because I suspect
> it depends on the memory size.  I think it would be quite unusual for
> a window to start 1MB under the nice 256MB boundary, but I'm not sure
> I'm ready to say that's always illegal.
> 
> On these machines, the [mem 0xbff00000-0xbfffffff] area is actually
> reported as reserved in the E820 map, and I first thought we could
> simply rely on that.  But I'm not really comfortable with that either,
> because I don't think there's a dependable relationship between those
> E820 entries and ACPI and PCI devices.  For one thing, I experimented
> with Windows, and it happily places PCI devices in reserved areas,
> and I think we're likely to trip over more BIOS bugs if we rely on
> something Windows doesn't.
> 
> I suspect Windows would blow up, too, if we could somehow fill up the
> rest of the window and force it to allocate the bottom.  But since
> it's only a 1MB area, I think that would be very difficult to do
> unless there's some way to tweak PCI BARs before booting Windows.
> 

If we put PCI devices in E820 RESERVED areas that's a bug, plain and
simple.  We should absolutely not doing so!

To some degree I don't care if Windows does or not ... that is the
documented mechanism for reserving address space, and we should respect
that.  Furthermore, we use the same mechanism internally for reserving
address space.

Furthermore, the only potentially bad outcome is reserving excessive
address space, which is in general safer than the opposite.

So let's just fix this.

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