linux-kernel - Re: [patch] floppy: suspend/resume fix

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, 12 Nov 2006 21:29:41 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Mikael Pettersson <mikpe@...uu.se>
Cc:	mingo@...e.hu, akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [patch] floppy: suspend/resume fix

On Sun, Nov 12, 2006 at 09:47:08PM +0100, Mikael Pettersson wrote:
> On Sun, 12 Nov 2006 19:40:01 +0000, Russell King wrote:
> > On Sun, Nov 12, 2006 at 07:09:53PM +0100, Ingo Molnar wrote:
> > > 
> > > * Mikael Pettersson <mikpe@...uu.se> wrote:
> > > 
> > > > Sorry, no joy. The first access post-resume still fails and generates:
> > > 
> > > ok, then someone who knows the floppy driver better than me should put 
> > > the right stuff into the suspend/resume hooks :-)
> > 
> > At a guess, what's probably happening is that the floppy drive, when
> > powered on after resume, reports "disk changed" because it doesn't
> > know any better.
> > 
> > We interpret "disk changed" to mean the disk has been removed and
> > possibly changed (which _is_ correct) and thereby abort any further
> > IO (irrespective of resume.)
> > 
> > Now, consider the following two scenarios:
> > 
> > 1. You suspend and then resume, leaving the disk in the floppy drive.
> > 
> > 2. You suspend, remove the floppy disk, insert a totally different disk
> >    in the same drive, and then resume.
> > 
> > What should you do?  (Hint: without reading the disk and comparing it
> > with what you have cached you don't know if the disk has been changed
> > or not.)
> > 
> > If you argue that in case (1) you should continue to allow IO, then
> > you potentially end up scribbling over a disk when someone does (2).
> > 
> > So I'd argue that the behaviour being seen by Mikael is the _safest_
> > behaviour, and the most correct behaviour given the limitations of
> > the hardware.
> 
> Note that my usage scenario consists of separate I/O commands:
> 
> 1. boot
> 2. tar cf /dev/fd0 somefile
> 3. tar tvf /dev/fd0
> 4. suspend (close lid) and later resume (open lid) 
> 5. tar tvf /dev/fd0 (this one fails since 2.6.18-rc1)
> 
> Ages and ages ago the floppy driver would cache data so that
> after e.g. one "tar tvf /dev/fd0" command, a new "tar tvf /dev/fd0"
> wouldn't actually do any I/O. But nowadays, at least in all 2.6
> kernels, that's not done and both "tar tvf /dev/fd0" commands
> will read the media.
> 
> Thus I don't see any excuse for the kernel failing step 5 above.

In which case isn't the real regression that it does IO?

Nevertheless, I give you two options:

1. Abort all IO do inserted floppy disk after resume.
2. Corrupt replaced floppy disk after resume.

You have to pick one and exactly one.  Which is inherently less risky to
the end user?

(I'm not saying that I can change the behaviour; I'm merely trying to
point out that you're arguing for an inherently dangerous behaviour.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/