linux-kernel - Re: data corruption: revalidating a (removable) hdd/flash on re-insert

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 05 Nov 2008 11:04:58 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Pavel Machek <pavel@...e.cz>
CC:	Kay Sievers <kay.sievers@...y.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: data corruption: revalidating a (removable) hdd/flash on	re-insert

Pavel Machek wrote:
> On Wed 2008-11-05 00:22:51, Michael Tokarev wrote:
>> Pavel Machek wrote:
[]
>>> So can we simply claim 'media changed' on last close/unmount? Sure,
>>> sometimes media was not changed, but that only hurts performance, not
>>> correctness... ?

>> Well, that's what my tiny proggy, which I used here to work around the
>> problem, does.  It constantly opens/closes the /dev/sdFOO, every 0.5s
>> currently (I don't think I will be able to replace a media faster than
>> half a second :), in order to catch REMOVALs of media -- because when
>> the drive does not see the media anymore, it correctly reports that
>> the media has changed...

> Ok, so we you need to do is to put it into kernel and activate it
> via blacklist...?

I'm fine with my solution.. ;)  Especially once Kay suggested to
look at /proc/mounts for notifications.

Original problem was that I didn't understand what happens, and
blamed kernel for "breaking" the working device (it looks like
it never worked in the first place, it was just that we never hit
the bug before).  Once the problem become clear (thanks Kay!),
I wrote the proggy mentioned above - it's obviously a gross hack,
but it stops the corruption for me.

Generally the solution can be one of the 3:

a) leave it as it is now, since it had never been bought up
   before and hence does not affect many people.  And because
   even if it was, it becomes less and less of a problem with
   bad drives going away slowly...

b) to use a mechanism like blacklist in kernel to force
   invalidation on CLOSE automatically for such drives (not
   when it really necessary as my program detects - on REMOVAL).
   Less efficient than my  solution, but much easier to deal
   with in kernel.

c) I will use my variant for my problem.. while finding a
  replacement for the bad hardware.

So no, I'm not asking to put that proggy into the kernel.. ;)
For kernelspace solution that'd be a much simple way.  If at
all.

So to summary: if it is EASY (read: trivial) to do such blacklist
in kernel space, I'd do it right away, because potentially it
is still possible to see similar corruptions elsewhere.  If not,
just forget the case as "solved for the reporter" ;)

Thanks!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/