From: "Michael H. Warfield" <mhw@wittsend.com>
To: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: root@mauve.demon.co.uk, linux-kernel@vger.kernel.org
Subject: Re: Switching Kernels without Rebooting?
Date: Thu, 12 Jul 2001 10:15:13 -0400 [thread overview]
Message-ID: <20010712101513.A439@alcove.wittsend.com> (raw)
In-Reply-To: <200107121211.NAA10270@mauve.demon.co.uk> <200107121254.HAA89768@tomcat.admin.navo.hpc.mil>
In-Reply-To: <200107121254.HAA89768@tomcat.admin.navo.hpc.mil>; from pollard@tomcat.admin.navo.hpc.mil on Thu, Jul 12, 2001 at 07:54:10AM -0500
On Thu, Jul 12, 2001 at 07:54:10AM -0500, Jesse Pollard wrote:
> > > On Wed, 11 Jul 2001, C. Slater wrote:
> > > >Would anyone else like to point out some other task somewhat related
> > > >and have me do it? :-)
> > > >
> > > >> > Before you even try switching kernels, first implement a process
> > > >> > checkpoint/restart. The process must be resumed after a boot
> > > >> > using the same
> > > >> > kernel, with all I/O resumed. Now get it accepted into the kernel.
> > > >>
> > > >> Hear, hear! That would be a useful feature, maybe not network servers,
> > > >> but for pure number crunching apps it would save people having to write
> > > >> all the state saving and recovery that is needed now for long term
> > > >> computations.
> > > >
> > > >Get a computer with hibernation support. That's just about what it is.
> > >
> > > Bzzzt wrong anser. Hibernation stops the entire kernel. checkpoint restart
> > > stops processes, saves the entire state of the process. hibernation
> > > is just halt the processor.
> >
> > Hibernation may not be.
> > I've just suspended to disk after the list line, pulled the power supplies,
> > taken the RAM chip out, shorted the pins to make really sure, then powered
> > back up.
> > Everything just resumed fine.
> >
> > All I'd need to do kernel migration is a quick vi of the
> > disk file.
> >
> > (well, almost)
> That sounds more like a memory dump to disk, and reload after power restored.
> Either that or possibly a separate power supply for RAM (something like a
> trickle discharge capacitor; I've read that some capacitors can hold a charge
> for about 3 days. Whether that would work for a large RAM or not, I have no
> idea).
It's a suspend to disk. Lots of Laptops can do it and my Toshiba
Tecra 8100 can do it from the BIOS if I have a magic Windows partition with
an appropriate suspend file in it (which would be unencrypted, which would
be unacceptable - so I had to look for a Linux solution for the suspend
to disk problem).
Check out the swsusp project up at Source Forge
<http://sourceforge.net/projects/swsusp/>. It allows me to suspend
into the swap space by hitting Alt-SysRQ-D. Great for changing
batteries on laptops (and, no, normal suspend does not survive a battery
change) but also REALLY GREAT for forensic security analysis of compromised
systems. I hit the console of a compromised system and hit Alt-SysRq-D
and it flushs the dirty buffers, dumps memory to swap (preserving all
my "volatiles") and the shuts down. I can snapshot the hard drive and
then restart the system where it left off for live running analysis. If
that gets screwed up, I can restore the image again and restart again from
the same spot again. I've also got all the memory and CPU state in that
disk image for "in-vitro" analysis by tools like Weitse's "The Coroner's
Toolkit".
But that doesn't solve ANY of the problems with changing the kernel
itself. Suspending and restoring the system is the easy part (and swsusp
still has some problems restoring X Windows). Restoring a system to
a different kernel is orders of magnitude worse, if not down right
impossible for all the reasons given over internal structures and
interfaces.
I would LOVE to have something like swsusp in the main line kernel,
however, just so I didn't have to convince IT departments to apply this
custom kernel patch to their production systems BEFORE they get their butts
kicked by some snott nosed script kiddie. :-/
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
>
> Any opinions expressed are solely my own.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
next prev parent reply other threads:[~2001-07-12 14:16 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-12 1:03 Switching Kernels without Rebooting? Torrey Hoffman
2001-07-12 1:24 ` C. Slater
2001-07-12 10:07 ` Jesse Pollard
2001-07-12 12:11 ` Ian Stirling
2001-07-12 12:54 ` Jesse Pollard
2001-07-12 14:15 ` Michael H. Warfield [this message]
2001-07-12 23:21 ` swsusp [was Re: Switching Kernels without Rebooting?] Pavel Machek
2001-07-12 23:17 ` Switching Kernels without Rebooting? Pavel Machek
2001-07-12 20:47 ` Wilfried Weissmann
-- strict thread matches above, loose matches on Subject: below --
2001-07-13 1:11 tas
2001-07-13 3:45 ` Ian Stirling
2001-07-12 15:32 Jesse Pollard
2001-07-12 12:23 Jesse Pollard
2001-07-12 14:55 ` Ralf Baechle
2001-07-12 4:48 Frank Davis
2001-07-12 5:08 ` John Alvord
2001-07-13 9:10 ` Chuck Hemker
[not found] <994895240.21189@whiskey.enposte.net>
2001-07-12 0:10 ` Stuart Lynne
2001-07-11 9:52 David Balazic
2001-07-11 10:08 ` Laramie Leavitt
2001-07-11 19:12 ` H. Peter Anvin
2001-07-11 15:19 ` C. Slater
[not found] <NOEJJDACGOHCKNCOGFOMOEKECGAA.davids@webmaster.com>
2001-07-10 20:43 ` C. Slater
2001-07-11 3:50 ` FORT David
2001-07-11 9:10 ` Helge Hafting
2001-07-11 15:41 ` C. Slater
2001-07-12 10:16 ` Helge Hafting
2001-07-11 22:12 ` Paul Jakma
2001-07-11 22:14 ` Rik van Riel
2001-07-11 22:36 ` C. Slater
2001-07-11 23:44 ` Andreas Dilger
2001-07-12 1:17 ` C. Slater
2001-07-12 15:39 ` Rik van Riel
2001-07-12 16:23 ` Albert D. Cahalan
2001-07-12 17:37 ` Mike Borrelli
2001-07-12 18:05 ` Rik van Riel
2001-07-13 10:07 ` Pau Aliagas
2001-07-12 18:48 ` Chris Friesen
2001-07-12 10:12 ` Ralf Baechle
2001-07-12 15:32 ` Rik van Riel
2001-07-11 22:36 ` David Schwartz
2001-07-12 7:23 ` Kai Henningsen
2001-07-12 10:05 ` Helge Hafting
2001-07-13 6:50 ` Kai Henningsen
2001-07-12 17:58 ` Hua Zhong
2001-07-11 22:46 ` Kip Macy
2001-07-11 23:02 ` Rik van Riel
2001-07-12 0:31 ` Jesse Pollard
2001-07-12 1:10 ` Hua Zhong
2001-07-11 23:36 ` H. Peter Anvin
2001-07-12 7:23 ` Ville Herva
2001-07-10 18:42 C. Slater
2001-07-10 18:50 ` Chris Wedgwood
2001-07-10 21:11 ` Jesper Juhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010712101513.A439@alcove.wittsend.com \
--to=mhw@wittsend.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pollard@tomcat.admin.navo.hpc.mil \
--cc=root@mauve.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox