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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAE9FiQUbKu-UWRBMJwn-fTH+LnEpODnOW+kGHg1FCtTZ3oDepQ@mail.gmail.com>
Date:	Tue, 31 Mar 2015 11:16:11 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	David Miller <davem@...emloft.net>
Cc:	David Ahern <david.ahern@...cle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: d63e2e1f3df breaks sparc/T5-8

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.

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.

Thanks

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