Ok -good that there is a discussion taking shape
(while it lasts).

--- SODA Noriyuki <soda@sra.co.jp> wrote:
> >>>>> On Fri, 11 Mar 2005 01:00:08 -0800 (PST),
> 	"Kamal R. Prasad" <kamalpr@yahoo.com> said:
> 
> > The bigger question is, can this be integrated
> into the src tree
> > of netbsd?
> 
> It's not sure that implementing checkpoint feature
> in the kernel
> is the way to go, it's usually done in a userspace
> library in
> the UNIX world.

The typical checkpointing mechanism is used freeze and
thaw processes -when they are functioning properly.
  What I have outlined in my paper is that, due to bad
pointer access or buffer overflow or any such arbit
thing, the process space can get corrupted. I want the
user to define during program execution -certain
fallback points. Should the process receive a SIGSEGV,
it will most likely happen quite some time after the
program has gone awry. Any recovery mechanism that is
part of the process address space is also susceptible
to the same errors that are causing a segfault.
 So, I have taken as much functionality as possible
out of process space and put it into the kernel.

> One of the reasons why it's done in userlevel
> instead of kernel is
> that checkpointing has to store references to files
> as pathnames, and
> usual UNIX kernel doesn't remember pathnames once
> the file is opened.
> 

My patch doesn't remember pathnames. It constructs
pathnames pased on struct proc fields (p_comm,
p_pid..)

> Dragonfly solves this problem by using a file handle
> instead
> of a pathname as the file reference.
> But this has at least two problems.
> - To implement process migration, a pathname is more
> portable
>   than a file handle. For example, if the
> checkpointing framework
>   uses a file handle, and /lib is a local
> filesystem, a reference
>   to /lib/libc.so.12 on a machine cannot work on a
> different machine,

The scheme which I have implemented allows the user to
specify the program execution pts where he saves
process state and restore them. The data and stack
segment are quite vulnerable to corruption. If both of
these are corrupted, you will have a problem executing
your dump routine itself. Dragonfly has made use of
generic_elf_coredump() -which saves you from that
trouble.
 I just don't want the end user to be aware that data
is actually being dumped to device. He does a
tsetjmp() and tlongjmp() without being aware of whats
going on.

>   Oppositely, if the checkpointing framework uses a
> pathname
>   as a file reference, such reference just works.
>   (BTW, this is what Tim Rightnour pointed out in a
> private
>   conversation.)

The checkpointing framework in dragonfly allows you to
hand the kernel a fd, and write its contents to disk
and have another process execute the file (possibly
after user modifies it). That is something of a
security risk -and you are actually longjmp()ing into
another process's address space. What if more than
user uses the shell to resume execution of a
checkpoint file?
  What I have on hand tells the kernel to save
context, and only the same process can resume
execution at a saved pt. User doesn't need access to
the file and kernel can save it with root permissions
(and possibly encrypt it too). This one does not
violate the process model (which IMHO dragonfly does).

> - Exposing file handles to userland has certain
> security risks.

What I have is something of a checkpoint descriptor
-which tsetjmp() returns. The descriptor is passed by
userland to the kernel -which then uses it to
construct a pathname.

>   This is especially problematic at checkpoint
> restarting time.
>   That's why Dragonfly allows only wheel group to do
> checkpointing
>   by default.

My patch ensures any and every unix process can
checkpoint -without getting into any conflict.

>   Also, I'm not sure that exposing file handles to
> usual user is
>   always safe for all filesystems. At least both
> NetBSD and Dragonfly
>   allow only root to use getfh(2) systemcall. But it
> seems Dragonfly
>   actually exposes file handles for every user who
> can open the file,
>   because their coredump file includes file handles
> of the file
>   descriptors when the process dumps core.
>   (from DragonflyBSD's
> sys/kern/imgact_elf.c:elf_putfiles())
>   Using a pathname doesn't have such security risks.
> 
Yeah -though I wouldn't want to comment on which
implementation is better.

> So, I recommmend to use userlevel checkpoint library
> for now.
> NetBSD pkgsrc already includes pkgsrc/devel/chkpt,
> for example.

If you realize that I want to save and resume a
program that is a victim of a denial of service attack
or some arbit thing, which the programmer didn't plan
for -but is causing a coredump, you would appreciate a
recovery mechanism that is INDEPENDENT of process
address space.

regards
-kamal


------------------------------------------------------------
Kamal R. Prasad
UNIX systems consultant 
kamalp@acm.org

In theory, there is no difference between theory and practice. In practice, there is:-).
------------------------------------------------------------


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/