Due to security reasons the systemd-spawn mode is no longer
supported in service.
Also fix the default binding address to be in local cwd not
to start global service by chance.
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>
Grabbed from kernel. Probably worth to gather
all bits manipulators here in future.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch(set) is inspired by similar from Andrey Vagin sent
sime time earlier.
The major idea is to artificially fail criu dump or restore at
specific places and let zdtm tests check whether failed dump
or restore resulted in anything bad.
This particular patch introduces the ability to tell criu "fail
at X point". Each point is specified with a integer constant
and with the next patches there will appear places over the
code checking for specific fail code being set and failing.
Two points are introduced -- early on dump, right after loading
the parasite and right after creation of the root task.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch change the build chain to not use pie objects in the crtools
executable.
This done by building the shared source files twice:
1. for parasite/restorer as '<file>-pie-build.o'
2. for crtools as '<file>.o'
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Merge arch/*/vdso.c files in vdso.c.
The merge has been done by copying arch/x86/vdso.c in vdso.c since it
contains patch a67e9f7bb9 ("vdso: don't play with a function exit code").
The commit f9ae6d9dd4 ("Replace remaining hard-coded TASK_SIZE use")
pushed in the aarch64 has been replicated since it should be cross
platform.
CC: Christopher Covington <cov@codeaurora.org>
CC: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Acked-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
- Move relocs application into a separate file which get
compiled as a regular C file in criu (pie/pie-relocs.[ch])
- Move types used by piegen into pie/piegen/uapi/types.h
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
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>
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>
This sounds strange, but we kinda need one. Here's the
justification for that.
We heavily open /proc/pid/foo files. To speed things up we
do pid_dir = open("/proc/pid") then openat(pid_dir, foo).
This really saves time on big trees, up to 10%.
Sometimes we need line-by-line scan of these files, and for
that we currently use the fdopen() call. It takes a file
descriptor (obtained with openat from above) and wraps one
into a FILE*.
The problem with the latter is that fdopen _always_ mmap()s
a buffer for reads and this buffer always (!) gets unmapped
back on fclose(). This pair of mmap() + munmap() eats time
on big trees, up to 10% in my experiments with p.haul tests.
The situation is made even worse by the fact that each fgets
on the file results in a new page allocated in the kernel
(since the mapping is new). And also this fgets copies data,
which is not big deal, but for e.g. smaps file this results
in ~8K bytes being just copied around.
Having said that, here's a small but fast way of reading a
descriptor line-by-line using big buffer for reducing the
amount of read()s.
After all per-task fopen_proc()-s get reworked on this engine
(next 4 patches) the results on p.haul test would be
Syscall Calls Time (% of time)
Now:
mmap: 463 0.012033 (3.2%)
munmap: 447 0.014473 (3.9%)
Patched:
munmap: 57 0.002106 (0.6%)
mmap: 74 0.002286 (0.7%)
The amount of read()s and open()s doesn't change since FILE*
also uses page-sized buffer for reading.
Also this eliminates some amount of lseek()s and fstat()s
the fdopen() does every time to catch up with file position
and to determine what sort of buffering it should use (for
terminals it's \n-driven, for files it's not).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The AUFS support code handles the "bad" information that we get from
the kernel in /proc/<pid>/map_files and /proc/<pid>/mountinfo files.
For details see comments in sysfs_parse.c.
The main motivation for this work was dumping and restoring Docker
containers which by default use the AUFS graph driver. For dump,
--aufs-root <container_root> should be added to the command line options.
For restore, there is no need for AUFS-specific command line options
but the container's AUFS filesystem should already be set up before
calling criu restore.
[ xemul: With AUFS files sometimes, in particular -- in case of a
mapping of an executable file (likekely the one created at elf load),
in the /proc/pid/map_files/xxx link target we see not the path
by which the file is seen in AUFS, but the path by which AUFS
accesses this file from one of its "branches". In order to fix
the path we get the info about branches from sysfs and when we
meet such a file, we cut the branch part of the path. ]
Signed-off-by: Saied Kazemi <saied@google.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently we build vDSO handling code for all archs provided
in the source code having some "common" parts inside pie/vdso.c,
pie/vdso-stub.c, vdso-stub.c and vdso.c. This were more or
less well but in new linux kernels (starting from 3.16 presumably)
the vDSO has been significantly reworked so every architecture
must have own vDSO handling engine (just like the kernel does).
So in this patch we move vDSO code to arch specific and because
aarch64 actually doesn't implement proxification yet due to
kernel restrictions -- we drops it out. When there will be
kernel support we bring it back in proper arch/aarch64
implementation.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Alexander Kartashov <alekskartashov@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch splits the file arch/x86/vdso.c into machine-independent
and machine-dependent parts by moving the routine vdso_init()
from the file vdso.c. The routine seems to be suitable for all
architectures supporting the vDSO.
The ARM version of the routine is moved to the source vdso-stub.c
that is supposed to be the vDSO proxy stub implementation for
architectures that don't provide the vDSO. The build scripts are
adjusted as well to enable selection between the full-fledged
and stub vDSO proxy implementations.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Looks-good-to: Cyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Pavel reported that in case if there a big number
of small vmas present in the dumpee we're reading
/proc/pid/pagemap too frequently.
To speedup this procedue we inroduce pagemap cache.
The interface is:
- pmc_init/pmc_fini for cache initialization and freeing
- pmc_get_map to retrieve specific PMEs array for VMA area
v2:
- Move internal constants to pagemap-cache.c
- Make PAGEMAP_LEN to accept virtual address/size
- Don't adjust low bound in caching mode to save a couple of code bytes
Reported-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The top-level makefile defines an ARCH_DIR variable. Always use
it rather than referencing ARCH directly, since ARCH may be set
by the user on the command line and that raw input may not be
what needs to be used internally.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
For inotify/fanotifies we cannot always open inodes by a
handle and have to scan directories searching for the inode
path :(
Fortunately, in most of the containers' cases fsnotifies are
put in "typical" places. These are used as hints for scanner.
The best way to go is use openvz's ploop over such filesystems.
Long term solution is to fix NFS to provide opening by handle.
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Here is nothing interecting. If a file can't be dumped by criu,
plugins are called. If one of plugins knows how to dump the file,
the file entry is marked as need_callback. On restore if we see
this mark, we execute plugins for restoring the file.
v2: Callbacks are called for all files, which are not supported by CRIU.
v3: Call plugins for a file instead of file descriptor. A few file
descriptors can be associated with one file.
v4: A file descriptor is opened in a callback. It's required for
restoring anon vmas.
v5: Add a separate type for unsupported files
v6: define FD_TYPES__UNSUPP
v7: s/unsupp/ext (external)
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Libraries (plugins) is going to be used for dumping and restoring
external dependencies (e.g. dbus, systemd journal sockets, charecter
devices, etc)
A plugin can have the cr_plugin_init() and cr_plugin_fini functions for
initialization and deinialization.
criu-plugin.h contains all things, which can be used in plugins.
v2: rename lib to plugin
v3: add a default value for a plugin path.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Makes the criu RPC socket socket-activated with
systemd [1], meaning that systemd will create and listen to
the UNIX socket /var/run/criu-srvice.socket
on behalf of criu until a connection comes in, when it will
then pass control of the socket, along with the first connection
over to a newly spawned criu daemon.
This is similar to inetd, but criu stays around after getting
started, listening itsself on the socket.
[1] http://0pointer.de/blog/projects/socket-activation.html
v2: stripped down sd-daemon.[ch]
moved units to scripts/sd
v3: stripped down further by removing unneeded includes
Signed-off-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It is been found that BTRFS uses per subvolume device
numbering scheme which causes some of our tests to fail
if they are laying on this filesystem.
Here we introduce minimal engine which parses subvolumes
present on mount point.
The interface is two functions
- btrfs_parse_mountinfo: this one parses subvolume and caches the results
- is_btrfs_subvol: test if device id is laying on subvolume
In the code we assume that cpu we're running on
is little endian, thus if one day we run on big
ending machine the code must be updated accordingly.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
On restore we need differetn types of memory allocation.
Here's an engine that tries to generalize them all. The
main difference is in how the buffer with objects is being
grown up.
There are 3 types of memory allocations:
1. shared memory -- objects, that will be used by all criu
children, but will not reach the restorer
2. shared remapable -- the same, but restorer would need
access to them, i.e. -- buffer with objects will get
remapped into restorer
3. private -- the same, but allocatedby each task for itself
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Right now we have an ability to launch the C/R service from root
and execure dump requests from unpriviledged users. Not to be bad
guys, we deny dumping tasks belonging to user, that cannot be
"watched" (traced, read /proc, etc.) by the dumper.
In the future we will use this "engine" when launched with suid
bit, and (probably) will have more sophisticated policy.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The criu service is a daemon, that opens a unix socket and listens for
incoming requests. The requests will be declared in protobuf/rpc.proto
and for now will only contain the 'dump' request.
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Same as kernel provides, adopted from Linux sources.
strlcpy is similar to strncpy but _always_ adds \0
at the end of string even if destination is shorter.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
These contain linkage between number, data type and routines
for pb messages we write/read to/from image files. Most of them
have simple number-type-routines mapping, so introduce a generating
script for that.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There will be two entities handled:
1. tun file -- an opened char device with misc major and tun minor
that can be attached to item #2
2. tun netdevice -- another type of links
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Move image object descriptors to own image-desc
file(s). This allow to reuse the code in other tools.
I had to move show declarations to cr-show.h as well.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Move protobuf object descriptors to own protobuf-desc
file(s). This allow to reuse the code in other tools.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
During criu startup we need to fill symbol table of own
run-time vdso provided by the kernel. We will need this
data for vdso proxy.
Because this functions are not used in restorer code,
we move them out of PIE (since PIE code must remain
as small as possible).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We'll have one more "image" file generated by dump and (surprisingly)
restore commands -- the stats one. It will contain in a single pb
object all the statistics collected by dump/restore.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
One of such things we use right now is the device for anon shmem
mappings backing. In the furure this can be extended to check for
various kernel features.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Now we have 2 forms of storing pages -- legacy pages.img and
new pagemap + pages image. We'll have one more (ovz) and the
pagemap + pages will be stacked (snapshot restore). Thus it's
handy to have this as an page-reader object.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We'll send them over network soon, so prepare abstraction layer for
this. Shmem is not on this scheme yet.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The page-pipe is an object, that can accumulate pages inside it. It
consists of list of page-pipe-bufs, which in turn has a pipa, an
array of iovecs that describe the pages' locations and some stats.
Users of it are supposed to vmsplice pages into pipes to accumulate
then for later use, and vmsplice them from pipes when required.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
They are really depends on CPU we're running on.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is a bit tricky since the build infrastructure
we're switching to is targeted to per-directory targets
if simplified Makefiles are used.
So I did the following
- move rules to compile general sources to Makefile.crtools
- main Makefiles now simply calls for scritps/Makefile.build
help to generate built-in.o target
Also note that we clean up suffixes for implicit rules with
.SUFFIXES:
this is done on purpose to eliminate any possible side effect
in future -- all rules _must_ be described explicitly.
Because of implicit rules used in zdtm building procedure
I can't use of stict makefile mode and add
MAKEFLAGS := -r
to the top of the general Makefile. This should be done
one day latter (if ever).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
