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: <20081030114747.GL15171@hawkmoon.kerlabs.com>
Date:	Thu, 30 Oct 2008 12:47:47 +0100
From:	Louis Rilling <Louis.Rilling@...labs.com>
To:	Andrey Mirkin <major@...nvz.org>
Cc:	Oren Laadan <orenl@...columbia.edu>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Cedric Le Goater <clg@...ibm.com>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [Devel] Re: [PATCH 0/9] OpenVZ kernel based
	checkpointing/restart

On Thu, Oct 30, 2008 at 10:02:44AM +0400, Andrey Mirkin wrote:
> > > kernel. Also we will need a functionolity to create processes with
> > > predefined PID. I think it is not very good to provide such ability to
> > > user space. That is why we prefer in OpenVZ to do all the job in kernel.
> >
> > This is the weak side of creating the processes in user space -
> > that we need such an interface. Note, however, that we can
> > easily "hide" it inside the interface of the sys_restart() call,
> > and restrict how it may be used.
> 
> Of course we can "hide" it somehow, but anyway we will have a hole and that is 
> not good.
> 
> Anyway we should ask everyone what they think about user- and kernel- based 
> process creation.
> Dave, Serge, Cedric, Daniel, Louis what do you think about that?

Frankly, I'm not convinced (yet) that one approach is better than the other one.
I only *tend* to prefer kernel-based, for the reasons explained below. I know
that there are arguments in favor of userspace (I've at least seen
security-related ones), but I let their authors detail them (again).

In Kerrighed this is kernel-based, and will remain kernel-based because we
checkpoint a distributed task tree, and want to restart it as mush as possible
with the same distribution. The distributed protocol used for restart is
currently too fragile and complex to rely on customized user-space
implementations. That said, if someone brings very good arguments in favor of
userspace implementations, we might consider changing this.

Without taking distributed restart into account, I also tend to prefer
kernel-based, mainly for two (not so strong) reasons:
1) this prevents userspace from doing weird things, like changing the task tree
and let the kernel detect it and deal with the mess this creates (think about
two threads being restarted in separate processes that do not even share their
parents). But one can argue that userspace can change the checkpoint image as
well, so that the kernel must check for such weird things anyway.
2) restart will be more efficient with respect to shared objects.

Louis

-- 
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ