linux-kernel - Re: [PATCH]PCI:disable resource decode in PCI BAR detection

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:	Fri, 14 Sep 2007 17:53:58 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc:	Greg KH <gregkh@...e.de>, Matthew Wilcox <matthew@....cx>,
	Shaohua Li <shaohua.li@...el.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH]PCI:disable resource decode in PCI BAR detection

Ivan Kokshaysky wrote:
> On Fri, Sep 14, 2007 at 08:30:59AM -0600, Robert Hancock wrote:
>> Do you have an example of specific hardware that exhibits this problem?
> 
> Well, first two results of google search for "disable bar when sizing":
>  http://lkml.org/lkml/2002/12/21/95
>  http://lkml.org/lkml/2002/12/20/110

In the first one, Linus talks about a USB controller whose SMM code 
chokes on the BAR being disabled. That explanation seems odd to me. If 
it chokes on the BAR disabled, how doesn't it choke on the BAR being 
moved to a different location, which is unavoidable during probing?

Also, I think we do USB handoff from the BIOS much earlier than we used 
to, which likely prevents these issues.

In the second one, he mentions that "So the secondary rule to "don't 
turnoff MEM or IO accesses" is "never allocate real PCI BAR resources at 
the top of memory". Well, unfortunately, the second one isn't possible 
to meet given that we have boards with the MMCONFIG up there, so 
disabling the decode is the only thing we can do. That whole discussion 
was also based on the fact that it wasn't necessary to solve problems. 
This is no longer a theoretical problem. We now have real problems that 
we need this in order to solve.

> 
>> So far after a similar patch has been in -mm for months there have been 
>> no reports of any such problems.
> 
> You cannot compare user base of -mm and release kernels. Also, note
> that we're talking about maybe 0.01% of systems running Linux.
> And similar patch appeared in various trees several times over the last
> decade and every time it had to be reverted.
> 
>> This isn't guaranteed to help. I don't think it is only integrated 
>> graphics that could cause this problem, I think that an add-on PCI 
>> Express card can do this as well. Depending on the chipset memory decode 
>> rules, any PCI or PCI Express device with a BAR large enough could cause 
>> issues.
> 
> No, it's impossible for several reasons. Most obvious one is that a PCI-E
> bridge does isolate stuff quite nicely.

It's not impossible at all. In fact I'm quite sure (Jesse can confirm) 
that in the case of the board he was using, it was an add-in graphics 
card where he saw this problem.

The fact is that in the case of MMCONFIG overlap with PCI BARs, which 
one takes priority is completely undefined. In the case of this Intel 
chipset, clearly the PCI Express device connected to the northbridge had 
higher decode priority than the MMCONFIG aperture.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

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