linux-kernel - Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

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: <46552067.8090107@shaw.ca>
Date:	Wed, 23 May 2007 23:19:35 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Olivier Galibert <galibert@...ox.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...e.de>, Chuck Ebbert <cebbert@...hat.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard
 resources

Jesse Barnes wrote:
> On Wednesday, May 23, 2007 8:20:14 Linus Torvalds wrote:
>> On Wed, 23 May 2007, Linus Torvalds wrote:
>>> Sure. I think mmconfig is perfectly sane if it falls back to conf1
>>> accesses for legacy stuff..
>> .. but without a regression, it's obviously a post-2.6.22 thing, I guess I
>> should make that clear, just because I think people send me patches after
>> -rc1 way too eagerly just because they think it fixes a bug.
>>
>> Basically if it's not somethign that has _ever_ worked some way, it's not
>> a bug, it's a feature ;)
> 
> No, I know better than to send something after your merge window closes.  I 
> have no desire to be flamed even further on this topic.  :)
> 
> And come to think of it, adding the enable/disable bits might be good even 
> with the patch to make legacy accesses go through type 1, since PCIe BAR 
> probing is probably done the same way (I haven't looked) and so we might run 
> into the same problems there.

I think that disabling decode on non-host-bridge devices during the BAR 
sizing is something we should at least try, indeed.

The issue I have with forcing legacy config space accesses to type1 is 
that it would make it much less obvious if the MMCONFIG access wasn't 
working properly. You'd likely be able to boot up but then wonder why 
something that does extended config space accesses didn't work or hung 
the box. As I mentioned before, either we trust the MMCONFIG or we 
don't, and if we decide that we don't on a particular box, we should 
really be shutting it off entirely. Hopefully with the ACPI reservation 
checking patch and the disable-decode-during-BAR-sizing patch
we wouldn't need to add that restriction.

But yes, post-2.6.22 for all of this :-)

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