linux-kernel - Re: A kexec approach to hibernation

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: <1180944874.27018.2.camel@nigel.suspend2.net>
Date:	Mon, 04 Jun 2007 18:14:34 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	vgoyal@...ibm.com, Jeremy Maitin-Shepard <jbms@....edu>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	Pavel Machek <pavel@....cz>
Subject: Re: A kexec approach to hibernation

Hi again.

On Mon, 2007-06-04 at 10:05 +0200, Rafael J. Wysocki wrote:
> On Monday, 4 June 2007 07:22, Nigel Cunningham wrote:
> > Hi.
> > 
> > I can see that the idea of writing a kernel image from using another
> > kernel sounds nice and clean initially, but the more we get into the
> > details (yes, I am listening, even though I said nothing before now),
> > the more it's sounding like the cure is worse than the disease.
> > 
> > To get rid of process freezing, we're talking about:
> > * making hibernation depend on depriving the user of 32 or 64M of
> > otherwise perfectly usable memory (thereby making hibernation on
> > machines with less memory impossible)
> > * requiring them to set up kexec or kdump (I don't understand the
> > difference, sorry) or some new variation
> > * adding interfaces to tell kexec/dump/whatever what pages need to be
> > saved and reloaded
> > * adding convolutions in which at resume time we boot one kernel, switch
> > to another kernel to do the loading and then switch back again to the
> > resumed kernel (assuming I understand what you're suggesting).
> > 
> > It all sounds terribly complicated and confusing to me, and that's
> > before I even begin to think about how this second kernel could possibly
> > write the image to an encrypted device or LVM or such like that the
> > first kernel knows about and might use now.
> > 
> > Can't we just get the freezer right and be done with it?
> 
> My feelings about this are pretty much the same. :-)
> 
> At least, there still is room for improvements within the current approach,
> so first I'd like to improve it as much as reasonably possible and then to
> think of alternatives, if need be.

Agreed. I'm not for a moment denying that the current freezer could be
better, but biffing it out the window just doesn't seem to be the
appropriate solution at the moment.

Regards,

Nigel

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)