linux-kernel - Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

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:	Sun, 25 Mar 2007 13:49:58 -0800 (PST)
From:	David Lang <david.lang@...italinsight.com>
To:	Jörn Engel <joern@...ybastard.org>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	Matt Mackall <mpm@...enic.com>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Artem Bityutskiy <dedekind@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Frank Haverkamp <haver@...t.ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

On Sun, 25 Mar 2007, Jörn Engel wrote:

> On Wed, 21 March 2007 12:25:34 +0100, Thomas Gleixner wrote:
>> On Wed, 2007-03-21 at 12:05 +0100, Jörn Engel wrote:
>>>
>>> Also LogFS currently requires erasesizes of 2^n.
>>
>> Last time I talked to you about that, you said it would be possible and
>> fixable.
>
> Actually, no.  LogFS is not broken, there is nothing to fix.
>
> And there is no fundamental reason why UBI should export blocks with
> non-power-of-two sizes.  UBI currently consists of two parts that are
> intimately intertwined in the current implementation, but have
> relatively little connection otherwise.
>
> 1. Logical volume management.
> 2. Static volumes.
>
> Logical volume management can just as easily move its management
> information into a table, instead of having it spread across all blocks.
> Blocks can keep their original size.  Since you have to scan flash
> anyway, you can also scan for a table, compare a magical number and do
> some extra check to protect yourself against a UBI image inside some
> logical volume.  No big deal.

if you are being paranoid about write cycles putting the write count in the 
block you are writing avoids doing an erase/write elsewhere

although, since you can flip bits to 1 without requireing an erase you could 
sacrafice some space and say that your table has a normal counter for the number 
of times the block has been erased, but a 'tally counter' where you turn one bit 
on each time you erase the block, and when you fill up the tally block you 
re-write the entire table, clearing all the tallys. if you have relativly large 
eraseblocks it seems like you could afford to sacrafice the space in your master 
table to avoid erases of it

IIRC someone said that the count per block was 128 bits? if so you could have a 
master table with a 32 bit integer (4B writes) + 96 bits of tally so that you 
would only have to re-write the table when a block on the flash has been erased 
96 times. with this approach the wear on your table is unlikely to be a factor 
until the point where you are loosing a lot of other eraseblocks due to wear 
(at which point you could shift to a different block for your table, or retire 
the flash)

David Lang