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:	Tue,  2 Aug 2016 12:26:53 -0600
From:	Ross Zwisler <ross.zwisler@...ux.intel.com>
To:	linux-kernel@...r.kernel.org
Cc:	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Dan Williams <dan.j.williams@...el.com>,
	Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
	linux-nvdimm@...ts.01.org, "Lee, Chun-Yi" <jlee@...e.com>,
	stable@...r.kernel.org#v4.2+
Subject: [PATCH v2] libnvdimm, nd_blk: mask off reserved status bits

The "NVDIMM Block Window Driver Writer's Guide":

http://pmem.io/documents/
http://pmem.io/documents/NVDIMM_DriverWritersGuide-July-2016.pdf

defines the layout of the block window status register.  For the July 2016
version of the spec linked to above, this happens in Figure 4 on page 26.

The only bits defined in this spec are bits 31, 5, 4, 2, 1 and 0.  The rest
of the bits in the status register are reserved, and there is a warning
following the diagram that says:

  Note: The driver cannot assume the value of the RESERVED bits in the
  status register are zero. These reserved bits need to be masked off, and
  the driver must avoid checking the state of those bits.

This change ensures that for hardware implementations that set these
reserved bits in the status register, the driver won't incorrectly fail the
block I/Os.

Signed-off-by: Ross Zwisler <ross.zwisler@...ux.intel.com>
Reviewed-by: Lee, Chun-Yi <jlee@...e.com>
Cc: Dan Williams <dan.j.williams@...el.com>
Cc: stable@...r.kernel.org # v4.2+
---

Changes from V1:
 - Rebased onto the v4.8 merge tree.  As Joey points out the ND BLK code
   recently moved from drivers/acpi/nfit.c to drivers/acpi/nfit/core.c.
   Since we were in the merge window for v4.8 I didn't know what to use as
   a baseline, so I just used v4.7, which was apparently incorrect.  Sorry
   about that.

 - Added Joey's reviewed-by.

For stable kernels v4.2 and beyond the v1 patch for drivers/acpi/nfit.c
applies cleanly and should be used.

---
 drivers/acpi/nfit/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 8c234dd..80cc7c0 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1527,11 +1527,12 @@ static u32 read_blk_stat(struct nfit_blk *nfit_blk, unsigned int bw)
 {
 	struct nfit_blk_mmio *mmio = &nfit_blk->mmio[DCR];
 	u64 offset = nfit_blk->stat_offset + mmio->size * bw;
+	const u32 STATUS_MASK = 0x80000037;
 
 	if (mmio->num_lines)
 		offset = to_interleave_offset(offset, mmio);
 
-	return readl(mmio->addr.base + offset);
+	return readl(mmio->addr.base + offset) & STATUS_MASK;
 }
 
 static void write_blk_ctl(struct nfit_blk *nfit_blk, unsigned int bw,
-- 
2.9.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ