linux-kernel - Re: Hibernation Redesign

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: <200707120946.05435.nigel@nigel.suspend2.net>
Date:	Thu, 12 Jul 2007 09:46:04 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Jeremy Maitin-Shepard <jbms@....edu>
Cc:	Miklos Szeredi <miklos@...redi.hu>, rjw@...k.pl, a1426z@...ab.com,
	jeremy@...p.org, pavel@....cz, nickpiggin@...oo.com.au,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Hibernation Redesign

Hi.

On Wednesday 11 July 2007 23:16:41 Jeremy Maitin-Shepard wrote:
> Nigel Cunningham <nigel@...el.suspend2.net> writes:
> 
> [snip]
> 
> > No other _proper_ solutions have been proposed. Everyone who suggests 
removing 
> > the freezer also suggests implementing it all over again. It might be 
sending 
> > SIGSTOP to everything. It might be shifting the desk chairs around and 
> > creating a completely new kernel context, but they always have the same 
> > goal - stopping the existing activity, and they all come with their own 
> > issues (even if they're not obvious yet because the alternatives are 
> > currently vapourware to one extent or another).
> 
> I'll certainly admit the kexec idea is vaporware currently, but it does
> differ in a significant way from freezer-based approaches, such that I
> don't think it should be referred to as just another implementation of a
> freezer.  Specifically, it doesn't require that the "old kernel" be in a
> "consistent" state to a greater extent than suspend to ram; it is the
> case that all of the devices must be quiesced or shut down to some
> extent, but doing this without races and deadlocks (and without the
> freezer) is certainly very, very similar to what needs to be done for
> suspend to ram, which will need to be solved anyway.  Unlike the
> existing hibernate approaches, however, it will not be necessary to use
> any of the driver infrastructure once switched to the "save image"
> kernel, and thus it will not matter what locks are held, for instance.

Locks are not nearly the issue that you're making them out to be, and neither 
are most processes. It's only fuse that has caused this whole ding.

The lack of context from the original kernel is also going to be a problem. If 
you want to store the image on a local hard disk, the kernel being hibernated 
is going to need to do that for you, because it will need to use the 
information only it has regarding what swap is in use, how files on mounted 
filesystems map to devices and sectors and so on. It will need to somehow 
transfer that information from itself to the 'saving kernel'. In the end, the 
only advantage you'll get is that you don't have to worry about fuse 
processes anymore.

Frankly, I wish kexec was a viable alternative. I'm tired of working on kernel 
code, and would be perfectly happy to stop working on Suspend2 if kexec would 
work or if Rafael got swsusp to a point where the difference in features was 
minimal. But I just can't see that kexec is a viable alternative. Sorry.

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Content of type "application/pgp-signature" skipped