linux-kernel - Re: [PATCH 00/80] Kernel based checkpoint/restart [v18]

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]

Date:	Thu, 24 Sep 2009 15:41:39 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Oren Laadan <orenl@...rato.com>
Cc:	torvalds@...ux-foundation.org,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-api@...r.kernel.org, serue@...ibm.com, mingo@...e.hu,
	xemul@...nvz.org, orenl@...rato.com
Subject: Re: [PATCH 00/80] Kernel based checkpoint/restart [v18]

On Wed, 23 Sep 2009 19:50:40 -0400
Oren Laadan <orenl@...rato.com> wrote:

> Q: How useful is this code as it stands in real-world usage?
> A: The application can be single- or multi-processes and threads. It
>    handles open files (regular files/directories on most file systems,
>    pipes, fifos, af_unix sockets, /dev/{null,zero,random,urandom} and
>    pseudo-terminals. It supports shared memory. sysv IPC (except undo
>    of sempahores). It's suitable for many types of batch jobs as well
>    as some interactive jobs. (Note: it is assumed that the fs view is
>    available at restart).

That's encouraging.

> Q: What can it checkpoint and restart ?
> A: A (single threaded) process can checkpoint itself, aka "self"
>    checkpoint, if it calls the new system calls. Otherise, for an
>    "external" checkpoint, the caller must first freeze the target
>    processes. One can either checkpoint an entire container (and
>    we make best effort to ensure that the result is self-contained),
>    or merely a subtree of a process hierarchy.

What is "best effort"?  Will the operation appear to have succeeded,
only it didn't?

IOW, how reliable and robust is code at detecting that it was unable to
successfully generate a restartable image?

> Q: What about namespaces ?
> A: Currrently, UTS and IPC namespaces are restored. They demonstrate
>    how namespaces are handled. More to come.

Will this new code muck up the kernel?

> Q: What additional work needs to be done to it?
> A: Fill in the gory details following the examples so far. Current WIP
>    includes inet sockets, event-poll, and early work on inotify, mount
>    namespace and mount-points, pseudo file systems

Will this new code muck up the kernel, or will it be clean?

> and x86_64 support.

eh?  You mean the code doesn't work on x86_64 at present?


What is the story on migration?  Moving the process(es) to a different
machine?

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