To better understand the content of mm-<ID>.img and pagemap-<ID>.img
additional constant names have been added to better resolve the hex
value to symbolical names.
Signed-off-by: Adrian Reber <areber@redhat.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently device numbers are shown as plain integers, but in
pretty output it's nice to see the major:minor pairs.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Ruslan Kuprieiev <rkuprieiev@cloudlinux.com>
This patch implements checkpoint/restore functionality
for binfmt_misc mounts. Both magic and extension types
and "disabled" state are supported.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
For some ipv6 scope types (link local, amongo others), we need to tell the
kernel the ifindex of the interface whose address we want to bind to as
well as the address itself.
v2: use SO_BINDTODEVICE to get the ifname, and pass that through instead of
using netlink to grab all the ipv6 sockets via rtnetlink.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This commit adds basic support for dumping and restoring seccomp filters
via the new ptrace interface. There are two current known limitations with
this approach:
1. This approach doesn't support restoring tasks who first do a seccomp()
and then a setuid(); the test elaborates on this and I don't think it is
tough to do, but it is not done yet.
2. Filters are compared via memcmp(), so two tasks which have the same
parent task and install identical (via memory) filters will have those
filters considered to be the "same". Since we force all tasks to have
the same creds (including seccomp filters) right now, this isn't a
problem.
The approach used here is very similar to the cgroup approach: the actual
filters are stored in a seccomp.img, and each task has an id that points to
the part of the filter tree it needs to restore. This keeps us from dumping
the same filter multiple times, since filters are inherited on fork.
v2:
* remove unused seccomp_filters field from struct rst_info
* rework memory layout for passing filters to restorer blob
* add a sanity check when finding inherited filters
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Implementing c/r of bridges with slaves shouldn't be too hard (viz. the
comment), but this is all I need to for right now.
v2: remove extra debug statement
v3: * remember to close fd in dump_bridge
* use "known" buffer length and snprintf for spath in dump_bridge
* change brace style
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When restoring venet device we need to restore its
index as well, which actually possible with new iproute2
package but the problem is that the index itself lays
inside image file. We could use crit tool to extract
it but this would slowdon procedure signifantly (need
to run python which would parse the image, or need
to pass the index into environmnet from inside of
the CRIU itself).
So lets do a trick and simply created venet device
inside container by criu itself (thanks we support
creating venet via netlink interface now).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@odin.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Otherwise it's impossible to understand from which namespace
this path should be opened.
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There are still systems which do not support dirty memory tracking.
This offers an interface to query the dirty memory tracking availability
via the new feature check RPC.
This is in preparation of a p.haul change which will use this RPC
interface to automatically detect if pre-dumps should be executed
or not.
This change introduces an additional optional field in the
criu_request and criu_response message (features) which is a
'criu_features' message.
Right now only the check for the memory tracking feature is supported
in the message 'criu_features':
optional bool mem_track = 1;
v2: Instead of checking for memory tracking only, provide a generic
interface to check for arbitrary features.
v3: Do not use bitfields for feature encoding but protobuf optional
message parameters.
Signed-off-by: Adrian Reber <areber@redhat.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
They both can container the MS_READONLY flag. And in one case it will be
read-only bind-mount and in another case it will be read-only
super-block.
v2: set mnt and sb for one call of mount() when it's posiable
v3: return a comment which was deleted by mistake
v4: Fix the sentense about restoring mnt flags
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Some flags have known text description, e.g. flags on a file
or flags on vma. Add ability to show these flags in decoded
form (and encode them back into binary).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This option allows users to specify their own irmap paths to scan in the event
that they don't have a path in one of the hard coded hints.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To handle deleted bindmounts we simply create
the former directory bindmount lived at, mount
the target and remove the directory back.
For this sake we add @deleted entry into the image.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is here only to support the Linux Kernel between versions
3.18 and 4.2. After that, this workaround is not needed anymore,
but it will work properly on both a kernel with and without the bug.
The bug is that when a process has a file open in an OverlayFS directory,
the information in /proc/<pid>/fd/<fd> and /proc/<pid>/fdinfo/<fd>
is wrong, so we grab that information from the mountinfo table instead.
This is done every time fill_fdlink is called.
We first check to see if the mnt_id and st_dev numbers currently match
some entry in the mountinfo table. If so, we already have the correct mnt_id
and no fixup is needed.
Then we proceed to see if there are any overlayFS mounted directories
in the mountinfo table. If so, we concatenate the mountpoint with the
name of the file, and stat the resulting path to check if we found the
correct device id and node number. If that is the case, we update the
mount id and link variables with the correct values.
Signed-off-by: Gabriel Guimaraes <gabriellimaguimaraes@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Hui Kang <hkang.sunysb@gmail.com>
Looks-good-to: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
* Added functionality for dumping unnamed unix sockets.
When we call CRIU with dump option, for unnamed socket we
should pass it inode into --ext-unix-sk. Details about this problem
described in http://criu.org/External_UNIX_socket#What_to_do_with_socketpair.28.29-s.3F.
Usage example:
criu dump -D images -o dump.log -v4 --ext-unix-sk=4529709 -t 13506
* fix typo error in log output
Signed-off-by: Artem Kuzmitskiy <artem.kuzmitskiy@lge.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Unix sockets may be created with non-absolute (relative) path
(when kernel creates one it always use AT_FDCWD for name resolving),
So when we collect sockets we see them as having names without leading
slash.
In common cases for such sockets application doesn't change own
working directory after that but this is not always the true.
So we need to invent some name resolver. The good candidate is
IRMAP cache but after a number of testings I found that it might
slow down performance very dramatically. Thus we need some more
intelligent way here.
For a while, for common applications such as postfix, fetching
dumpee working directory and root is enough. So here what we do
- when socket get collected from diag interface we remember
its relative name parameters (device and inode) but postprone
name resolving to not bring perf penalty until really needed
- when we meet a socket to dump with relative name assigned we
try to use $cwd/name and $root/name for this socket to check
if it has been created in those directories. On success we
simply remember the directory in image and when restore such
socket call for chdir helper to change working dir and generate
relative name
v2:
- Use new unlink_stale to remove sockets we're to restore
- Use *at() helpers once we're changed working dir in bind_unix_sk
- Add more debug ouput
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Add checkpoint and restore of the Altivec and VSX registers.
Currently we rely on the return value of ptrace to detect if the CPU is
supporting these features or not. In the future, we should rely on the
AT_HWCAP vector and check feature at restart time.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Unfortunately, SECCOMP_MODE_FILTER is not currently exposed to userspace,
so we can't checkpoint that. In any case, this is what we need to do for
SECCOMP_MODE_STRICT, so let's do it.
This patch works by first disabling seccomp for any processes who are going
to have seccomp filters restored, then restoring the process (including the
seccomp filters), and finally resuming the seccomp filters before detaching
from the process.
v2 changes:
* update for kernel patch v2
* use protobuf enum for seccomp type
* don't parse /proc/pid/status twice
v3 changes:
* get rid of extra CR_STAGE_SECCOMP_SUSPEND stage
* only suspend seccomp in finalize_restore(), just before the unmap
* restore the (same) seccomp state in threads too; also add a note about
how this is slightly wrong, and that we should at least check for a
mismatch
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch adds support for checkpoint and restore of two linux security
modules (apparmor and selinux). The actual checkpoint or restore code isn't
that interesting, other than that we have to do the LSM restore in the restorer
blob since it may block any number of things that we want to do as part of the
restore process.
I tried originally to get this to work using libraries in the restorer blob,
but I could _not_ get things to work correctly (I assume I was doing something
wrong with all the static linking, you can see my draft attempts here:
https://github.com/tych0/criu/commits/apparmor-using-libraries ). I can try to
resurrect this if it makes more sense, to do it that way, though.
v2: lsm_profile lives in creds.proto instead of the task core, look in a more
canonical place for selinuxfs and don't try to special case any selinux
profile names.
v3: only allow unconfined selinux profiles
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch initiates the ppc64le architecture support in CRIU.
Note that ppc64 (Big Endian) architecture is not yet supported since there
are still several issues to address with this architecture. However, in the
long term, the two architectures should be addressed using the almost the
same code, so sharing the ppc64 directory.
Major ppc64 issues:
Loader is not involved when the parasite code is loaded. So no relocation
is done for the parasite code. As a consequence r2 must be set manually
when entering the parasite code, and GOT is not filled.
Furthermore, the r2 fixup code at the services's global address which has
not been fixed by the loader should not be run. Branching at local address,
as the assembly code does is jumping over it.
On the long term, relocation should be done when loading the parasite code.
We are introducing 2 trampolines for the 2 entry points of the restorer
blob. These entry points are dealing with r2. These ppc64 specific entry
points are overwritting the standard one in sigreturn_restore() from
cr-restore.c. Instead of using #ifdef, we may introduce a per arch wrapper
here.
CRIU needs 2 kernel patches to be run powerpc which are not yet upstream:
- Tracking the vDSO remapping
- Enabling the kcmp system call on powerpc
Feature not yet supported:
- Altivec registers C/R
- VSX registers C/R
- TM support
- all lot of things I missed..
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We need a custom flags to build 32bit varian of criu
on 64bit host system, lets pass @ldflags-y here for
that.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We will need it for x86-32 as well, not on ARM only.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
With this flag, external shared bind mounts are attempted to be resolved
automatically.
v2: don't always assume when the sharing matches that the mount matches
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Add the new mnt_entry->fsname member and change dump_one_mountpoint()
to save pm->fstype->name if fstype == FSTYPE__AUTO.
Change collect_mnt_from_image() to pass this ->fsname to decode_fstype()
which falls back to __find_fstype_by_name(fsname, true) if FSTYPE__AUTO.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The comment in find_fstype_by_name() says:
just mounting anything is wrong
and this is true in general, but:
almost every fs has its own features
this is not true in a sense that a lot of supported filesystems do not
need any special processing: FSTYPE__PROC, FSTYPE__SYSFS, and more. More
importantly, this logic does not allow to spicify from the command line
that (say) currently unsupported hugetlbfs can "just work", do_new_mount()
should only pass the right name/options.
This patch adds the new FSTYPE__AUTO code, find_fstype_by_name(name) adds
the new entry if fsname_is_auto(name) returns true. We do not care that
different fstype's can have the same FSTYPE__AUTO code, fstype->code has
no meaning unless we need to do something special with this fs, but in
this case it should not be FSTYPE__AUTO by definition.
Note: currently find_fstype_by_name() just returns true, it is obviously
pointless to "dump" until we teach "restore" to handle FSTYPE__AUTO.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
1. If a fuse connection is present, but there are no fuse mounts of that type
in the mount namespace, don't refuse to dump.
2. If there are mounts of that type in the container but they are external,
we're going to bind them anyway, so there's no fuse-specific things that
need to be done, so it is safe to dump.
v2: check that the fstype is fuse as well
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Opening current tty is tricky: first slave peer should
be opened and session restored, and only then we can
open /dev/tty. So that I made rst_info to carry
additional list @tty_ctty where all current ttys
get gathered and opened after slave peers were
brought to live.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is required to use criu swrk in libcontainer.
v2: remove useless function declaration
allow to set inherit_fd only for swrk
v3: check swrk out of loop
Cc: Saied Kazemi <saied@google.com>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There are two places where we store IP addresses (both IPv4 and IPv6).
Mark them with custom option and print them in compressed form for
--pretty output.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Ruslan Kuprieiev <kupruser@gmail.com>
Instead of generating intermideate files with .SECONDARY
helper lets calculate proto deps on the fly.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently we run into lots of race conditions when building in
multithreded mode.
Reported-by: Mr Jenkins
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Acked-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Pavel reported that decimal values for some fields are hard to read,
because people used to see hex values in there. Unfortunately, json
doesn't support hex representation of integers, so we can only store
them as hex strings. Not all field need to be represented as hex
strings, so this set introduces a custom field option called "criu"
to use in our proto files. One should use [(criu).hex = true] to mark
which field should be represented as a hex string. pb2dict module
from pycriu package will look into field options and if he finds that
criu.hex is set to True, it will convert such field to/from hex string.
Though, such behaviour is optional and user can request it by specifying
--format hex when calling crit decode("crit encode" in its turn, detects
such fields automatically and doesn't require any special cmdline options
to be set).
We need our proto files to compile with both protoc and
protoc-c compilers, which requires creating google/protobuf
directory with a symlink to /usr/include/google/protobuf/
descriptor.proto to make protoc-c and generated c files happy.
Reported-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When AIO context is set up kernel does two things:
1. creates an in-kernel aioctx object
2. maps a ring into process memory
The 2nd thing gives us all the needed information
about how the AIO was set up. So, in order to dump
one we need to pick the ring in memory and get all
the information we need from it.
One thing to note -- we cannot dump tasks if there
are any AIO requests pending. So we also need to
go to parasite and check the ring to be empty.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>