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: <alpine.LFD.0.98.0704261000480.9964@woody.linux-foundation.org>
Date:	Thu, 26 Apr 2007 10:07:24 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
cc:	Pekka Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

On Thu, 26 Apr 2007, Linus Torvalds wrote:
> 
> Once you have that snapshot image in user space you can do anything you 
> want.

Side note: the exception, of course, is page out more. The swap device has 
to be read-only.

We actually have support for that mode (it's how "swapoff" works: it marks 
swap devices as not accepting _new_ entries, even though old entries are 
still valid). So you can have a fully running system, with 99% of memory 
swapped out, and still guarantee that you won't swap out anything *more* 
(which would destroy the swap image, which you don't want, since it's 
where a lot of the memory may end up being, in order to make the snapshot 
itself as small as possible)!

Anybody who cares can look at the code that messes with the the 
SWP_WRITEOK flag. You'd basically swap out enough to make the snapshot 
image fit comfortably in memory, and then you'd clear SWP_WRITEOK on all 
swap devices and return to user space. Or something very close to that.

But the point here is that we should actually really be able to have a 
fully working system, even _after_ we created the snapshot. I don't even 
think you should need any "initrd only" kind of situation.

If somebody can do that, with just those two system calls, I'll remove 
every other suspend-to-disk wannabe from the kernel in a heartbeat. I may 
have missed something subtle, of course, but I really *think* it should be 
doable.

			Linus
-
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/