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
| ||
|
Date: Wed, 16 Apr 2008 23:06:05 +0800 From: "Peter Teoh" <htmldeveloper@...il.com> To: "Alan Jenkins" <alan-jenkins@...fmail.co.uk> Cc: "Scott Lovenberg" <scott.lovenberg@...il.com>, linux-kernel@...r.kernel.org Subject: Re: RFC: Self-snapshotting in Linux On 4/16/08, Alan Jenkins <alan-jenkins@...fmail.co.uk> wrote: > Scott Lovenberg wrote: > > > Peter Teoh wrote: > > Maybe you load up another kernel to handle the snapshot, and then hand > > the system back to it afterwards? What do you think? > > > Isn't that just what Ying Huans kexec-based hibernation does? > This list is awesome. After I read up on this kexec-based hibernation thing: http://kerneltrap.org/node/11756 I realized it is about the same idea. Some differences though: My original starting point was VMWare's snapshot idea. Drawing an analogy from there, the idea is to freeze and restore back entire kernel + userspace application. For integrity reason, filesystem should be included in the frozen image as well. Currently, what we are doing now is to have a bank of Norton Ghost-based images of the entire OS and just selectively restoring back the OS we want to work on. Very fast - less than 30secs the entire OS can be restored back. But problem is that it need to be boot up - which is very slow. And there userspace state cannot be frozen and restored back. VMWare images is slow, and cannot meet bare-metal CPU/direct hardware access requirements. There goes Xen's virtualization approach as well. Another approach is this (from an email by Scott Lovenberg) - using RELOCATABLE kernel (or may be not?????I really don't know, but idea is below): a. Assuming we have 32G (64bit hardware can do that) of memory, but we want to have 7 32-bit OS running (not concurrently) - so then memory is partition into 8 x 4GB each - the lowest 4GB reserved for the current running OS. Each OS will be housed into each 4G of memory. When each OS is running, it will access its own partition on the harddisk/memory, security concerns put aside. Switching from one OS to another OS is VOLUNTARILY done by the user - equivalent to that of "desktop" feature in Solaris CDE. Restoring back essentially is just copying from each of the 4GB into the lowest 4GB memory range. Because only the lowest 4gb is used, only 32 bit instruction is needed, 64bit is needed only when copying from one 4GB memory partition into the lowest 4GB region, and vice versa. And together with using partitioning of harddisk for each OS, switching among the different OS kernel should be in seconds, much less than 1 minute, correct? Technically, does the above sound feasible? -- Regards, Peter Teoh -- 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