Date:	Thu, 04 Nov 2010 09:05:28 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Kapil Arya <kapil@....neu.edu>
CC:	Oren Laadan <orenl@...columbia.edu>,
	ksummit-2010-discuss@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, Gene Cooperman <gene@....neu.edu>,
	hch@....de
Subject: Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

Hello,

On 11/04/2010 04:40 AM, Kapil Arya wrote:
> (Sorry for resending the message; the last message contained some html
> tags and was rejected by server)

And please also don't top-post.  Being the antisocial egomaniacs we
are, people on lkml prefer to dissect the messages we're replying to,
insert insulting comments right where they would be most effective and
remove the passages which can't yield effective insults.  :-)

> In our personal view, a key difference between in-kernel and userland
> approaches is the issue of security.  The Linux C/R developers state
> the issue very well in their FAQ (question number 7):
>> https://ckpt.wiki.kernel.org/index.php/Faq :
>> 7. Can non-root users checkpoint/restart an application ?
>>
>> For now, only users with CAP_SYSADMIN privileges can C/R an
>> application. This is to ensure that the checkpoint image has not been
>> tampered with and will be treated like a loadable kernel-module.

That's an interesting point but I don't think it's a dealbreaker.
Kernel CR is gonna require userland agent anyway and access control
can be done there.  Being able to snapshot w/o root privieldge
definitely is a plust but it's not like CR is gonna be deployed on
majority of desktops and servers (if so, let's talk about it then).

> Strategies like these are easily handled in userspace.  We suspect
> that while one may begin with a pure kernel approach, eventually,
> one will still want to add a userland component to achieve this kind
> of flexibility, just as BLCR has already done.

Yeap, agreed.  There gotta be user agents which can monitor and
manipulate userland states.  It's a fundamentally nasty job, that of
collecting and applying application-specific workarounds.  I've only
glanced the dmtcp paper so my understanding is pretty superficial.
With that in mind, can you please answer some of my curiosities?

* As Oren pointed out in another message, there are somethings which
  could seem a bit too visible to the target application.  Like the
  manager thread (is it visible to the application or is it hidden by
  the libc wrapper?) and reserved signal.  Also, while it's true that
  all programs should be ready to handle -EINTR failure from system
  calls, it's something which is very difficult to verify and test and
  could lead to once-in-a-blue-moon head scratchy kind of failures.

  I think most of those issues can be tackled with minor narrow-scoped
  changes to the kernel.  Do you guys have things on mind which the
  kernel can do to make these things more transparent or safer?

* The feats dmtcp achieves with its set of workarounds are impressive
  but at the same time look quite hairy.  Christoph said that having a
  standard userland C-R implementation would be quite useful and IMHO
  it would be helpful in that direction if the implementation is
  modularized enough so that the core functionality and the set of
  workarounds can be easily separated.  Is it already so?

Thanks.

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