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]
Date:   Mon, 26 Jun 2017 11:05:32 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     Andrew Lutomirski <luto@...nel.org>,
        Christoph Hellwig <hch@....de>,
        linux-nvme <linux-nvme@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] nvme: explicitly disable APST on quirked devices

On Mon, Jun 26, 2017 at 12:01 AM, Kai-Heng Feng
<kai.heng.feng@...onical.com> wrote:
> A user reports APST is enabled, even when the NVMe is quirked or with
> option "default_ps_max_latency_us=0".
>
> The current logic will not set APST if the device is quirked. But the
> NVMe in question will enable APST automatically.
>
> Separate the logic "apst is supported" and "to enable apst", so we can
> use the latter one to explicitly disable APST at initialiaztion.

Reviewed-by: Andy Lutomirski <luto@...nel.org>

That being said, I smell a giant WTF here.  The affected hardware
seems to have APST on by default, and APST is buggy so the disk stops
working when APST is on.  So here's the $1M question: how does the
system *boot*?  After all, it's running for a while before the kernel
gets around to turning off APST, and I really doubt that BIOS does
this.

Here's a wild theory: what if the problem on all these disks is
actually our CSTS polling?  Could it be that some of the disks
implement CSTS reads in firmware and malfunction if CSTS is read while
in PS4?  This would be a blatant spec violation, but that's never
stopped anyone before...

--Andy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ