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: <48FCBD24.7070902@cs.columbia.edu>
Date:	Mon, 20 Oct 2008 13:17:24 -0400
From:	Oren Laadan <orenl@...columbia.edu>
To:	Andrey Mirkin <major@...nvz.org>
CC:	devel@...nvz.org, containers@...ts.linux-foundation.org,
	Pavel Emelyanov <xemul@...nvz.org>,
	linux-kernel@...r.kernel.org, Dave Hansen <dave@...ux.vnet.ibm.com>
Subject: Re: [Devel] Re: [PATCH 0/9] OpenVZ kernel based checkpointing/restart



Andrey Mirkin wrote:
> On Saturday 18 October 2008 03:33 Dave Hansen wrote:
>> On Wed, 2008-09-03 at 14:57 +0400, Andrey Mirkin wrote:
>>> This patchset introduces kernel based checkpointing/restart as it is
>>> implemented in OpenVZ project. This patchset has limited functionality
>>> and are able to checkpoint/restart only single process. Recently Oren
>>> Laaden sent another kernel based implementation of checkpoint/restart.
>>> The main differences between this patchset and Oren's patchset are:
>> Hi Andrey,
>>
>> I'm curious what you want to happen with this patch set.  Is there
>> something specific in Oren's set that deficient which you need
>> implemented?  Are there some technical reasons you prefer this code?
> 
> Hi Dave,
> 
> Right now my patchset (v2) provides an ability to checkpoint and restart a 
> group of processes. The process of checkpointing and restart can be initiated 
> from external process (not from the process which should be checkpointed).

Both patchsets share the same design, namely be able to checkpoint and
restart multiple processes, with the operation initiated by an external
processes.

I deliberately left out the part that handles multiple processes to
keeps things simple for initial review, and until we decide on the
question of kernel- or user- based process creation on restart.

> Also I think that all the restart job (including process forking) should be 
> done in kernel, as in this case we will not depend on user space and will be 
> more secure. This is also implemented in my patchset.

I'm not convinced that creating the processes in the kernel makes it
more secure.  Can you elaborate ?  for the discussion, let's compare
these two basic scenarios:

1) container and processes are created in user space; each process
calls "sys_restart()" which eventually calls "do_restart()" that
does kernel-based restart.

2) container and processes are created in kernel space; each process
calls "do_restart()" to do kernel-based restart.

In fact, creating in user based makes it easier to enforce capabilities
and limits of the user. It also simplifies the debugging significantly,
and allows us to delegate the entire issue of containers and namespace
management back to user space, where it probably belongs.

On the other hand, doing it in kernel space likely to produce simpler
code for the creation of the processes.

Thanks,

Oren.

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