[lkml]   [2010]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Ksummit-2010-discuss] checkpoint-restart: naked patch

    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):
    >> :
    >> 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?



     \ /
      Last update: 2010-11-04 09:11    [W:0.032 / U:4.716 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site