linux-kernel - Re: Back to the future.

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:	Sat, 28 Apr 2007 11:28:06 -0700 (PDT)
From:	David Lang <david.lang@...italinsight.com>
To:	Oliver Neukum <oliver@...kum.org>
cc:	Nigel Cunningham <nigel@...el.suspend2.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

On Sat, 28 Apr 2007, Oliver Neukum wrote:

> Am Samstag, 28. April 2007 01:50 schrieb David Lang:
>> 3. make mounted filesystems read-only (possibly with snapshot/checkpoint)
>> 4. unpause
>> 5. save image (with full userspace available, including network)
>> 6. shutdown system (throw away all userspace memory, no need to do graceful
>>     shutdown or nice kill signals, revert filesystem to snapshot/checkpoint if
>>     needed)
>
> And then you'll have people wonder why the server which sent out all
> those files has no log entries. You'd have to selectively unfreeze user
> space, which is a cure worse than the desease.
>
> Simply throwing away user space work is a bug. And no, you cannot say that
> it'll be redone away, as you are throwing away accepted input, too.

when you are doing a suspend-to-disk I disagree with you. whoever is doing the 
suspend knows what is going on, and they can decide what needs to be done.

the only case where you have 'unexpected' work being thrown away is if you are 
suspending a network server, and the process of suspending it is going to cut 
all the network connections anyway so it's not a seamless process. In this case 
it's fair to let the sysadmin choose between loosing some logs or doing some 
other step to prevent this from happening (which could be to shutdown the 
network service, or load a iptables rule to block the service)

however, most of the uses of suspend-to-disk are going to be single-user 
machines and in that case telling the user that anything that they do after 
issuing the suspend is going to be lost is a perfectly sane thing to do.

and for that matter, if the snapshot is cheap enough, some people may choose to 
cron the snapshot portion of a suspend-to-disk evvery few min as a safety net 
for something going wrong. In this case they really do want all of userspace to 
keep working after the snapshot.

David Lang