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-next>] [day] [month] [year] [list]
Message-ID: <878xb3l888.fsf@jbms.ath.cx>
Date:	Fri, 01 Jun 2007 16:39:51 -0400
From:	Jeremy Maitin-Shepard <jbms@....edu>
To:	linux-kernel@...r.kernel.org
Cc:	suspend2-devel@...ts.suspend2.net
Subject: A kexec approach to hibernation

I figured I'd throw this idea out, since although it is not perfect, it
has the potential to elegantly solve a lot of issues with hibernate.

Just as kexec can now be used to write a crashdump after a kernel panic,
a fresh kexec-loaded kernel (loaded into unused memory) could be used to
write the hibernate image of the existing kernel to disk, and then power
off the system (or suspend to ram, or anything else).  This avoids the
need for the original kernel to jump through hoops to hibernate itself
in place.

A hibernate sequence would be approximately as follows:
 
 1. Free some memory if needed or desired, and disable the swap device
    if it is going to be used to write the hibernate image.

 2. Load the fresh kernel in a chunk of available (possibly
    pre-allocated) memory (there must also be enough available memory
    for this kernel to use).

 3. Disable interrupts and stop all devices.

 4. Jump to the new kernel, passing whatever state information will be
    needed by it to know how to write the image.

 5. The new kernel loads, and then either kernel space or user space
     writes the necessary data from the old kernel to disk.

 6. The new kernel either powers off or suspends to ram.  If it suspends
    to ram, then it would need to be able to jump back to the old kernel
    when it resumes from ram.

The advantages of this approach include:

 - having a completely functional system (with a completely functional
   userspace) from which the image is written, without having to worry
   about messing up the state that is being saved (hell, the user could
   even do it via an interactive shell on the new kernel);

 - no need to worry about trying to use drivers while some processes are
   frozen;

 - no need for complicated process freezing; the same logic that can be
   used for suspend to ram should be sufficient;

 - no need for an atomic copy of memory, or any other complicated memory
   copying; the memory of the old kernel, including the page cache, can
   be written directly;

 - instead of needing a significant amount of free memory to store the
   atomic copy, only a few megabytes would needed to load and run the
   new kernel.

It may or may not be necessary to require that the new kernel used to
write the image is the same as the existing kernel; it will likely be
useful to require that it is built from the same sources and with a
similar config.  It would likely be useful, however, to either compile
out or (e.g. via the kernel command-line) disable the initialization of
drivers that will not be needed to write the image, such as sound
drivers, cdrom drivers, filesystems, and network drivers (if the image
is not to be written via the network).

Of course, if special initialization was needed under the original
kernel to set up the devices that will be used to write the image, such
as device mapper setup, or network initialization, that will have to be
repeated under the new kernel as well.  This is the principal
disadvantage to this approach, but since it must be done during resume
from hibernation in any case, it doesn't seem like a very significant
disadvantage.  The other disadvantage is that there would be the
delay of loading the fresh kernel; this may, however, only take a second
or two, which is relatively insignificant compared to the time required
to actually write the image, and the delay could be reduced by stripping
out unnecessary drivers from the image-writing kernel.

-- 
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ