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-next>] [day] [month] [year] [list]
Date:	Fri, 25 Sep 2015 17:09:13 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	linux-mtd@...ts.infradead.org,
	Artem Bityutskiy <dedekind1@...il.com>,
	Richard Weinberger <richard@....at>
Cc:	Andrea Scian <rnd4@...e-tech.it>,
	Bean Huo 霍斌斌 (beanhuo) 
	<beanhuo@...ron.com>,
	Karl Zhang 张双锣 (karlzhang) 
	<karlzhang@...ron.com>,
	Iwo Mergler <Iwo.Mergler@...commwireless.com>,
	"Jeff Lauruhn (jlauruhn)" <jlauruhn@...ron.com>,
	Stefan Roese <sr@...x.de>, linux-kernel@...r.kernel.org,
	Boris Brezillon <boris.brezillon@...e-electrons.com>
Subject: [PATCH 0/5] mtd: nand/UBI: add power-cut emulation

Hello,

This series aims at adding a power-cut emulation layer at the nandsim
level.
The final goal is to support MLC NAND emulation in nandsim in order to
validate the work done in the NAND, UBI and UBIFS layers to reliably
support those chips.

Even though the UBI layer already provides a power-cut emulation
infrastructure, I decided to add one at the nandsim layer for the
following reasons:
- IMO it is cleaner to isolate MLC NAND emulation in the NAND layer
- emulating unstable bits in UBI is not so easy: the unstable bits
  issue happens when a program or erase operation is interrupted (by a
  power-cut) while it is almost finished. In this case the next read
  operation will succeed (return the expected data), but not the following
  ones.
  Emulating this problem requires knowing which block/page was being
  accessed when the power-cut occurred, and if we want to validate that
  UBI (not UBIFS) is robust to such errors, we have to reattach the mtd
  partition to the UBI layer, and by doing that we loose the information
  of which page/block was being programmed/erased when the power-cut
  occurred.
  By implementing the power-cut emulation at the nandsim level, we can
  easily detach/attach the emulated device, and check still keep those
  information.
- emulating paired pages in UBI is a bit easier but still requires some
  knowledge about the pairing scheme (which differs from one chip to
  another), and I'm not sure yet how this will be exposed by the MTD/NAND
  layers.

This being said, I might be wrong in my assumptions, so feel free to
comment on that decision.

Regarding the code itself, this series adds a simple power-cut emulation
layer, and modifies the intermediate layers (NAND and UBI) to forward
emulated power-cut errors and let the UBIFS layer switch into read-only
mode.

Paired pages and unstable bits emulation is not part of the series, but
can be added on top of those changes by tweaking the actions taken in
nandsim when a power-cut is emulated.

Also, I'm not sure about the method used to inform NAND core when a
power-cut was emulated: I'm currently adding a virtual NAND status flag,
but adding a new field in the nand_chip struct might be a better approach.
This would also allow us to compile out code sections that are only useful
when doing NAND emulation.

Best Regards,

Boris

Boris Brezillon (5):
  mtd: nand: add basic stuff to support power-cut emulation
  mtd: nand: return -EROFS in case of power-cut emulation
  UBI: switch the UBI device in read-only mode when mtd returns -EROFS
  mtd: nand: nandsim: implement ->get_status()
  mtd: nand: nandsim: add support for power-cut emulation

 drivers/mtd/nand/nand_base.c |  34 ++++++--
 drivers/mtd/nand/nandsim.c   | 182 ++++++++++++++++++++++++++++++++++++++++---
 drivers/mtd/ubi/io.c         |   4 +-
 include/linux/mtd/nand.h     |   4 +
 4 files changed, 207 insertions(+), 17 deletions(-)

-- 
1.9.1

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ