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: <20190530205823.GA45696@google.com>
Date:   Thu, 30 May 2019 15:58:23 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Himanshu Madhani <hmadhani@...vell.com>
Cc:     Andrew Vasquez <andrewv@...vell.com>,
        Girish Basrur <gbasrur@...vell.com>,
        Giridhar Malavali <gmalavali@...vell.com>,
        Myron Stowe <mstowe@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Quinn Tran <quinn.tran@...gic.com>,
        Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: [EXT] VPD access Blocked by commit
 0d5370d1d85251e5893ab7c90a429464de2e140b

On Thu, May 30, 2019 at 07:33:01PM +0000, Himanshu Madhani wrote:

> We are able to successfully read VPD config data using lspci and cat
> command

Yes, you mentioned that in the very first email.  I was hoping you
would include the actual data, e.g., "cat vpd | xxd".  That would help
us figure out why you don't see the panic any more.  I suspect either:

  - new QLogic firmware fixed the structure of the VPD data so Linux
    no longer attempts to read past the end of the implemented region,
    or,

  - we still read past the end of the implemented VPD region, but the
    device doesn't report an error or the platform deals with the
    error without causing a panic.

> We also verified this same configuration on a SuperMicro X10SRA-F
> server (which i had sent in earlier email)’ and were able to verify
> that the VPD read was good and there were no errors on PCIe trace.

Since you saw no PCIe errors here, this suggests that new firmware has
changed the format of the VPD data.

> Given this information, Please consider reverting the patch until we
> further debug the issue and resolve as it is affecting general
> availability of our adapter.

1) The way Linux works is that you would post a patch that does the
revert you'd like to see done.

2) It's unlikely that a simple revert of 0d5370d1d852 ("PCI: Prevent
VPD access for QLogic ISP2722") is the right answer because that would
make Ethan's machine panic again.  It's possible that a QLogic
firmware update would avoid the panic, but we can't simply revert the
patch and force users to do that update.

If a QLogic firmware update indeed fixed the VPD format, I suggest
that you ask the folks responsible for the firmware to identify the
specific version where that was fixed and how the OS can figure that
out.

Then you could make a new quirk specific to this device that allows
VPD reads if the adapter has new enough firmware.  If it finds older
firmware, it could even print a message suggesting that users could
update the firmware if they need to read VPD data.

Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ