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:   Sat, 28 Jul 2018 09:28:58 +0800
From:   Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:     Richard Weinberger <richard@....at>
Cc:     martin bayern <Martinbayern@...look.com>, stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4.4 15/47] ubi: fastmap: Correctly handle interrupted
 erasures in EBA

On Thu, 2018-07-26 at 08:25 +0200, Richard Weinberger wrote:
> Ben,
> 
> Am Donnerstag, 26. Juli 2018, 04:12:54 CEST schrieb Ben Hutchings:
> > On Tue, 2018-07-10 at 20:24 +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Richard Weinberger <richard@....at>
> > > 
> > > commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
> > > 
> > > Fastmap cannot track the LEB unmap operation, therefore it can
> > > happen that after an interrupted erasure the mapping still looks
> > > good from Fastmap's point of view, while reading from the PEB will
> > > cause an ECC error and confuses the upper layer.
> > > 
> > > Instead of teaching users of UBI how to deal with that, we read back
> > > the VID header and check for errors. If the PEB is empty or shows ECC
> > > errors we fixup the mapping and schedule the PEB for erasure.
> > 
> > [...]
> > 
> > Isn't there a risk here, that a read error leads to erasing data that
> > might be recoverable if the read is retried?
> 
> Well, read error means that already something went very wrong. At other places
> in UBI wo also don't retry reading headers and consider it as fatal when we 
> are unable to read it.
> We could also read the EC header, but what do we gain from that?
> If the VID header is not readable we cannot check fastmap either.
> 
> What case exactly do you have in mind?

I suppose I'm thinking about data recovery from a flash device that has
become unreliable.  I'm not familiar with ubi; is there a read-only
mode where the erase wouldn't actually be performed?

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ