linux-kernel - Re: [testcase] test your fs/storage stack (was Re: [patch] ext2/3: document conditions when reliable operation is possible)

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]

Message-ID: <alpine.DEB.2.00.0908290931260.6822@asgard.lang.hm>
Date:	Sat, 29 Aug 2009 09:35:51 -0700 (PDT)
From:	david@...g.hm
To:	Pavel Machek <pavel@....cz>
cc:	Ric Wheeler <rwheeler@...hat.com>, Theodore Tso <tytso@....edu>,
	Florian Weimer <fweimer@....de>,
	Goswin von Brederlow <goswin-v-b@....de>,
	Rob Landley <rob@...dley.net>,
	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, mtk.manpages@...il.com,
	rdunlap@...otime.net, linux-doc@...r.kernel.org,
	linux-ext4@...r.kernel.org, corbet@....net
Subject: Re: [testcase] test your fs/storage stack (was Re: [patch] ext2/3:
 document conditions when reliable operation is possible)

On Sat, 29 Aug 2009, Pavel Machek wrote:

>> for flash drives the danger is very straightforward (although even then
>> you have to note that it depends heavily on the firmware of the device,
>> some will loose lots of data, some won't loose any)
>
> I have not seen one that works :-(.

so let's get broader testing (including testing the SSDs as well as the 
thumb drives)

>> you are generalizing that since you have lost data on flash drives, all
>> flash drives are dangerous.
>
> Do the flash manufacturers claim they do not cause collateral damage
> during powerfail? If not, they probably are dangerous.

I think that every single one of them will tell you to not unplug the 
drive while writing to it. in fact, I'll bet they all tell you to not 
unplug the drive without unmounting ('ejecting') it at the OS level.

> Anyway, you wanted a test, and one is attached. It normally takes like
> 4 unplugs to uncover problems.

Ok, help me understand this.

I copy these two files to a system, change them to point at the correct 
device, run them and unplug the drive while it's running.

when I plug the device back in, how do I tell if it lost something 
unexpected? since you are writing from urandom I have no idea what data 
_should_ be on the drive, so how can I detect that a data block has been 
corrupted?

David Lang
View attachment "fstest" of type "TEXT/PLAIN" (976 bytes)

View attachment "fstest.work" of type "TEXT/PLAIN" (426 bytes)