linux-kernel - Re: [PATCH] ubi: Reject MLC NAND

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:   Wed, 7 Mar 2018 02:57:20 +0100
From:   David Oberhollenzer <david.oberhollenzer@...ma-star.at>
To:     linux-mtd@...ts.infradead.org
Cc:     Pavel Machek <pavel@....cz>, Richard Weinberger <richard@....at>,
        boris.brezillon@...e-electrons.com, dedekind1@...il.com,
        tharvey@...eworks.com, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, marek.vasut@...il.com,
        cyrille.pitchen@...ev4u.fr, computersforpeace@...il.com,
        dwmw2@...radead.org
Subject: Re: [PATCH] ubi: Reject MLC NAND

On 03/07/2018 12:18 AM, Pavel Machek wrote:
> Now... Yes, handling flash is hard, MLC NAND is worst of the
> bunch. But...
> 
MLC is not just more flimsy than SLC NAND.

The real problem is that on MLC NAND, pages come in pairs.

Multiple voltage levels inside a single, physical memory cell are used to
encode more than one bit. Instead of just having pages that are twice as big,
the flash exposes them as *two different pages*. Those pages are usually not
ordered sequentially either, but according to a vendor/device specific
pairing scheme.

> Read disturb is not unique to MLC, right? Happens to all the flashes,
> its just that MLC has tighter margins for error.
> 
You don't just have more read disturb on a single page. Reading one page
will also affect the paired page as well.[0]

In addition to that, you also have program disturb. Even *writing successfully*
to the upper page of a pair also causes bit flips on the lower one, affecting
completely different data.[0]

This could be addressed using the experimental ubihealthd that crawls the flash
from time to time (at UBI level), making UBI notice and fix bit flips.[0]

> Power-cut. UBIFS is just not power-cut safe, right? My notes say that
> power-cut during erase could result in flash that contains all 1s, but
> will start showing errors very quickly. Again, not MLC specific. Can
> be solved with battery...
> 
> (And yes, there are some problems specific to MLC, where parts of page
> need to be written in specific order. Not sure how it affects
> ubifs. But it was not listed as a reason for the patch.)
> 

Both UBI and UBIFS were designed to be power cut tolerant.[1]

On MLC however, if you interrupt a write access to the upper page of a pair,
you will also corrupt the lower one, i.e. *data that was already written*,
which is a serious issue.[0]

Richard and Boris did spend a lot of time working on a solution for that at
UBI level which would currently still require a lot of testing and fine
tuning, but sadly we ran out of budget.

The proposed patch tries to prevent further bad surprises for people who try
to use UBI and UBIFS on top of MLC by making sure that UBI _refuses_ to run
on MLC (at least for now).

Regards,

David

[0] http://linux-mtd.infradead.org/doc/ubifs.html#L_ubifs_mlc
[1] http://linux-mtd.infradead.org/doc/ubifs.html#L_powercut

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)