Difference between revisions of "CR tools"
| Line 14: | Line 14: | ||
The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where crtools takes all the information it needs). | The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where crtools takes all the information it needs). | ||
| − | Which includes | + | Which includes |
| − | * Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo''') | + | * Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo'''). |
| − | * Pipes parameters | + | * Pipes parameters. |
| − | * Memory maps (via '''/proc/$pid/maps''') | + | * Memory maps (via '''/proc/$pid/maps'''). |
| − | The process dumper (lets call it simply the dumper further) does the following steps during checkpoint stage | + | The process dumper (lets call it simply the dumper further) does the following steps during checkpoint stage |
| − | # A '''$pid''' of a process group leader is obtained from the command line | + | # A '''$pid''' of a process group leader is obtained from the command line. |
# By using this '''$pid''' the dumper walks though '''/proc/$pid/status''' and gathers children '''$pids''' recursively. At the end we will have a process tree. | # By using this '''$pid''' the dumper walks though '''/proc/$pid/status''' and gathers children '''$pids''' recursively. At the end we will have a process tree. | ||
| − | # Then it takes every '''$pid''' from a process tree, sends ''SIGSTOP'' to every process found, and performs the following steps on each '''$pid''' | + | # Then it takes every '''$pid''' from a process tree, sends ''SIGSTOP'' to every process found, and performs the following steps on each '''$pid'''. |
| − | #* Collects VMA areas by parsing '''/proc/$pid/maps''' | + | #* Collects VMA areas by parsing '''/proc/$pid/maps'''. |
| − | #* | + | #* Seizes a task via relatively new ptrace interface. Seizing a task means to put it into a special state when the task have no idea if it's being operated by ptrace. |
| + | #* Core parameters of a task (such as registers and friends) are being dumped via ptrace interface and parsing '''/proc/$pid/stat''' entry. | ||
| + | #* The dumper injects a parasite code into a task via ptrace interface. This allows us to dump pages of a task right from within the task's address space. An injection procedure is pretty simple - the dumper scans executable VMA areas of a task (which were collected previously) and tests if there a place for <code>syscall</code> call, then (by ptrace as well) it substitutes an original code with <code>syscall</code> instructions and creates a new VMA area inside process address space. Finally parasite code get copied into the new VMA, the former modified code get restored. | ||
Revision as of 21:48, 14 October 2011
What CRtools is
CRtools is an utility to checkpoint/restore process tree. Unlike checkpoint/restore implemented completely in kernel space, it tries to achieve the same target mostly in user space.
Agenda
- Basic design (checkpoint == proc + SEIZE, restore == syscalls + execve)
- What's required from kernel
Basic design
Checkpoint
The checkpoint procedure relies heavily on /proc file system (it's a general place where crtools takes all the information it needs). Which includes
- Files descriptors information (via /proc/$pid/fd and /proc/$pid/fdinfo).
- Pipes parameters.
- Memory maps (via /proc/$pid/maps).
The process dumper (lets call it simply the dumper further) does the following steps during checkpoint stage
- A $pid of a process group leader is obtained from the command line.
- By using this $pid the dumper walks though /proc/$pid/status and gathers children $pids recursively. At the end we will have a process tree.
- Then it takes every $pid from a process tree, sends SIGSTOP to every process found, and performs the following steps on each $pid.
- Collects VMA areas by parsing /proc/$pid/maps.
- Seizes a task via relatively new ptrace interface. Seizing a task means to put it into a special state when the task have no idea if it's being operated by ptrace.
- Core parameters of a task (such as registers and friends) are being dumped via ptrace interface and parsing /proc/$pid/stat entry.
- The dumper injects a parasite code into a task via ptrace interface. This allows us to dump pages of a task right from within the task's address space. An injection procedure is pretty simple - the dumper scans executable VMA areas of a task (which were collected previously) and tests if there a place for
syscallcall, then (by ptrace as well) it substitutes an original code withsyscallinstructions and creates a new VMA area inside process address space. Finally parasite code get copied into the new VMA, the former modified code get restored.
