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] [day] [month] [year] [list]
Date:	Wed, 16 Apr 2008 14:31:23 -0400
From:	"Greg Freemyer" <greg.freemyer@...il.com>
To:	"Peter Teoh" <htmldeveloper@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"Kernel Newbies" <kernelnewbies@...linux.org>
Subject: Re: RFC: Self-snapshotting in Linux

On Wed, Apr 16, 2008 at 4:44 AM, Peter Teoh <htmldeveloper@...il.com> wrote:
> Sorry if this is a a crazy idea.....just be forewarned....
>
>  First, I would like to make a reference to VMWare's snapshot (name not
>  important, emphasize the idea) feature - hopefully u are familiar with
>  it.   This is a feature whereby u can freeze the entire OS (kernel +
>  userspace application running) and then later reload itself next time,
>  continuing where it left off, without reboot from ground zero.
>
>  Next, can I ask, is such a feature useful in Linux?   Ie, able to
>  restart the kernel + userspace application from where u left off, the
>  last time round.    Not JUST the normal suspend/resume feature, but
>  more important able to CHOOSE among the different available images for
>  u to resume on.   Eg, u want to freeze the current 2.6.25-rc6 kernel,
>  save it, and then restore back the 2.6.23-rc5 image, work on it, save
>  it, and then restore the previous image again.   All done without
>  virtualization as in the VMWare sense - which really is CPU intensive
>  and slow things  down a lot.   Now we can directly execute each OS
>  kernel image on the CPU, and since saving and restoring is quite fast
>  (eg, zipping up the entire physical memory before saving into
>  permanent storage) - I supposed this will be much faster than the
>  normal initialization/fsck work done normally....or did I missed out
>  anything?
>
>  Essentially, to reiterate the key idea:   able to snapshot the current
>  kernel+userspace permanent.....restore from another snapshot....and
>  then switch back again if needed etc.....will the implementation be
>  difficult...if not impossible????
>
>  --
>  Regards,
>  Peter Teoh

By using LVM-2 snapshots you can already do this with data drives.

So if you setup a XEN setup where the DomU boot drives are Dom0 LVs
you should be golden.

Ie. from Dom0 you can create/restore your snapshots of your DomU instances.

It may also be possible to make LVM snapshots work with the root
partition of the physical boot drive, but that would take initrd magic
I have never tried.

Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
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