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:   Thu, 08 Mar 2018 15:43:12 +0100
From:   Richard Weinberger <richard@....at>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     linux-mtd@...ts.infradead.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        Mark Vasut <marek.vasut@...il.com>,
        Boris BREZILLON <boris.brezillon@...e-electrons.com>,
        Brian Norris <computersforpeace@...il.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Artem Bityutskiy <dedekind1@...il.com>, tharvey@...eworks.com,
        stable <stable@...r.kernel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH] ubi: Reject MLC NAND

Linus,

Am Donnerstag, 8. März 2018, 14:42:16 CET schrieb Linus Walleij:
> On Sat, Mar 3, 2018 at 11:45 AM, Richard Weinberger <richard@....at> wrote:
> > While UBI and UBIFS seem to work at first sight with MLC NAND, you will
> > most likely lose all your data upon a power-cut or due to read/write
> > disturb.
> > 
> > In order to protect users from bad surprises, refuse to attach to MLC
> > NAND.
> > 
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Richard Weinberger <richard@....at>
> 
> I'm sorry to disturb in this interesting discussion about what
> "stable" really means as in "stable kernel".  Stable for who and
> in what sense, that seems to be the question.
> 
> But my main problem here is to understand who the consumers
> of the MLC NAND devices really are.
> 
> I hear some talk here about lab boards. But where is this
> really deployed, large-scale? And who are the people that
> will have their devices potentially not booting after this patch?
> 
> I am pretty sure these people are board support or
> customization consultants with work being done for some
> certain products, and not hobbyists and even less end
> consumers, right?

Correct.
I saw vendor specific kernels that have hardware and software hacks to make 
UBI on MLC NAND somehow work.
Somehow in terms of, the filesystem will die just a little later.

But these people do _not_ run a vanilla (stable) kernel.
We support mainline, nothing more, nothing less.

> What kind of devices are MLC NANDs being deployed in?
> Certainly not laptops, tablets and phones, they all use eMMC
> and even start to venture into UFS (unified flash storage).
> 
> What is using these flashes? Routers and switches? NAS boxes?
> Industrial control? Automotive?
> 
> Or are (God forbid, but would not surprise me) talking about a
> Linux instance running inside of eMMCs or UFS devices?

We need to clarify that even more. Upstream UBI and UBIFS cannot work with MLC 
NAND correctly. Any such product would die within days...
I have many MLC boards on my desk, by running a mainline kernel on them, I can 
kill every single one within a few minutes, either by plugging the power or 
triggering read-disturb.

As stated by David Woodhouse, it was a huge mistake by UBI to not reject MLC 
NAND from the very beginning.
The sole purpose of this patch is fixing that mistake and make it very clear.

Thanks,
//richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ