linux-kernel - Re: [PATCH 4.4 15/47] ubi: fastmap: Correctly handle interrupted erasures in EBA

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] [day] [month] [year] [list]

Message-ID: <2079260.rIAgkgY78I@blindfold>
Date:   Sat, 28 Jul 2018 07:56:09 +0200
From:   Richard Weinberger <richard@....at>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>
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

Ben,

Am Samstag, 28. Juli 2018, 03:28:58 CEST schrieb Ben Hutchings:
> > > 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?

We have a ready only mode, UBI enters this mode upon fatal errors.
But I don't see what this has to do with the case this patch addresses.
Here we need to recover from interrupted erases when fastmap is used.
With fastmap the mapping still looks valid to the upper layer but due to
a bad erase we might face later ECC errors and therefore we have to check
whether it is still valid upon first access.
If data is present, mapping is ok. If not (no data or ECC error), unmap it
to make the state sync with the upper layer.

Thanks,
//richard