linux-kernel - Re: Possible issue with dangling PCI BARs

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-next>] [day] [month] [year] [list]

Message-id: <4760B37E.3010002@shaw.ca>
Date:	Wed, 12 Dec 2007 22:22:22 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	benh@...nel.crashing.org
Cc:	linux-pci@...ey.karlin.mff.cuni.cz,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Possible issue with dangling PCI BARs

Benjamin Herrenschmidt wrote:
> On Thu, 2007-12-13 at 14:05 +1100, Benjamin Herrenschmidt wrote:
>> On Thu, 2007-12-13 at 14:00 +1100, Benjamin Herrenschmidt wrote:
>>
>>  .../...
>>
>> (oops, sent too fast)
>>
>>> So not only we can have a dangling BAR, but nothing prevent us to
>>> actually go turn IO or MEM decoding on in case it wasn't already the
>>> case on that device.
>> And I was about to say before I clicked "send".. can't we do something like
>> writing all ff's into the BAR at the same time as we clear res->start ? Isn't
>> that supposed to pretty much disable decoding on that BAR ? Or not... Probably
>> still better than leaving it to whatever dangling value it had no ?
> 
> Ok, reading some other threads, it seems that writing all ff's will not
> be a very good alternative on x86 machines where MMCONFIG sits up
> there...
> 
> I suppose there is nothing totally safe that can be done, thanks to
> Intel not thinking about making BARs individually enable/disable'able
> (or size-able without interrupting access, among other numerous fuckups
> in the PCI spec).
> 
> So if a BAR is left dangling, I think we -must- disable MEM and IO
> decoding on the whole device. In fact, the whole trick of passing a
> bitmask of required BARs to pci_enable_device_bars() in the first place
> doesn't fly.
> 
> Yuck.

We could do a bit better than that - a common use case with 
pci_enable_device_bars would be where the device has some IO space that 
we don't care about because we only want to use MMIO space. If we only 
want to enable MMIO BARs then we don't need to enable IO decoding, and 
in that case it doesn't matter if we failed to find space for the IO 
space and it overlaps something else.

It looks like we already handle the "not enabling IO decoding" part in 
this case, except that it doesn't look like we ever would disable the 
decoding if it was already enabled.

For the case where you say "I want to enable decoding for this MMIO BAR, 
but not that one", though, I don't see an obvious way to provide that 
guarantee with certainty. Normally, one would expect that if a BAR is 
mapped safely outside the decode window of a PCI bridge it's behind, 
that it won't ever see the requests and can't respond to them. However, 
the Intel chipset MMCONFIG overlap fiasco appears to show that this is 
not always the case and in some cases the device can see and respond to 
requests outside of the bridge's decode window (with higher decode 
priority than the MMCONFIG aperture, even)..

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