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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 12 Nov 2006 22:44:28 +0100
From:	Bodo Eggert <>
To:	Ingo Molnar <>, Mikael Pettersson <>,,
Subject: Re: [patch] floppy: suspend/resume fix

Russell King <> wrote:

> 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.

- If a user suspends with a floppy in the drive, it will mostly be an error,
  and he'll unsuspend in order to correct it.
- If it is no error, putting a different/modified floppy into the drive
  before resume is unlikely
- Even if somebody does this, you can mostly detect the different disk
  by comparing the first sector or just the FAT "serial number".

Therefore you can implement a relatively safe resume that will mostly DTRT
but destroy data in some unlikely cases, while doing the "safe thing" would
mostly cause a harmless (unless not noticed) kind of data loss and sometimes
safe you from real data loss.

I think you should let the user choose which foot to shoot.
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists