linux-kernel - Re: Back to the future.

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: <1177711666.4737.176.camel@nigel.suspend2.net>
Date:	Sat, 28 Apr 2007 08:07:46 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

Hi.

On Fri, 2007-04-27 at 14:44 -0700, Linus Torvalds wrote:
> 
> On Fri, 27 Apr 2007, Rafael J. Wysocki wrote:
> > 
> > Why do you think that keeping the user space frozen after 'snapshot' is a bad
> > idea?  I think that solves many of the problems you're discussing.
> 
> It makes it harder to debug (wouldn't it be *nice* to just ssh in, and do
> 
> 	gdb -p <snapshotter>

Make the machine being suspended a VM and you can already do that.

> when something goes wrong?) but we also *depend* on user space for various 
> things (the same way we depend on kernel threads, and why it has been such 
> a total disaster to try to freeze the kernel threads too!). For example, 
> if you want to do graphical stuff, just using X would be quite nice, 
> wouldn't it?

It would be nice, yes.

But in doing so you make the contents of the disk inconsistent with the
state you've just snapshotted, leading to filesystem corruption. Even if
you modify filesystems to do checkpointing (which is what we're really
talking about), you still also have the problem that your snapshot has
to be stored somewhere before you write it to disk, so you also have to
either

1) write some known static memory to disk before the snapshot and reuse
it for the snapshot,
2) ensure up to half the RAM is free for your snapshot or 
3) compress the snapshot as you take it, guessing beforehand how much
memory the compressed snapshot might take and freeing that might
4) reserve memory at boot time for the atomic copy so that 2) or 3) is
still done, but without having to free the memory. (Yuk!).

> But I do agree that doing everythign in the kernel is likely to just be a 
> hell of a lot simpler for everybody.

Indeed.

Nigel

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