linux-kernel - Re: d63e2e1f3df breaks sparc/T5-8

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20150331.141911.1147249607585406404.davem@davemloft.net>
Date:	Tue, 31 Mar 2015 14:19:11 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	yinghai@...nel.org
Cc:	david.ahern@...cle.com, bhelgaas@...gle.com,
	linux-pci@...r.kernel.org, sparclinux@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: d63e2e1f3df breaks sparc/T5-8

From: Yinghai Lu <yinghai@...nel.org>
Date: Tue, 31 Mar 2015 11:16:11 -0700

> On Tue, Mar 31, 2015 at 8:06 AM, David Miller <davem@...emloft.net> wrote:
>> Your patch only allows the condition behind resources that have 64-bits
>> of significance, but that is not what the document above says about
>> when this situation is allowed.
>>
>> Please implement the check either exactly as stated in the errata
>> document, or more loosely if that is not possible, rather than more
>> strictly than allowed.
>>
>> Your overly strict and restrictive checks are what got us into this
>> predicament in the first place. :-(
> 
> From that errata:
> ---
> Here are criteria that are sufficient to guarantee correctness for a
> given candidate BAR:
> 
> The entire path from the host to the adapter is over PCI Express.
> 
> No conventional PCI or PCI-X devices do peer-t o-peer reads to the
> range mapped by the BAR.
> 
> The PCI Express Host Bridge does no byte merging. (This is believed to
> be true on most
> platforms.)
> 
> Any locations with read side-effects are never the target of Memory
> Reads with the TH bit Set.
> See Section 2.2.5
> ---
> 
> We can verify first one that we have all pcie device all the way to
> the hostbridge.
> 
> But we can not verify or guarantee other three.

Lack of peer-to-peer reads we can assume, the byte merging we can
add as a per-controller attribute in the future if it turns out there
are some that do and it matters (I doubt this will ever be necessary)
and the side-effect issue is outside the scope of the PCI layer.

> System should get better about the constraints with system design.
> So if it would assign 64bit (and above 4G) mmio to those non-pref 64bit BAR,
> that means it already make sure system design will follow those criteria.
> and then we can safely set pref bit in resource flags.

I totally disagree, I think your test is too stringent and should be
significantly relaxed if not removed entirely.