- 14 Mar, 2017 33 commits
-
-
Dmitry Safonov authored
I copied __ptr_oob* checks from util-vdso.c. That will allow to check not only structure begin pointers, but structure end also. Before this patch code checked if strings section's header pointer is OOB, but it did it after dereferencing this pointer, which is meaningless. Now it checks: - OOB of sections table, - strings section's header should be inside sections table, - check strings section with it's length for OOB. In the very next patches I will add tests for this functions and other compel-related changes. Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
There is no longer phony compel target but compel/compel instead. Signed-off-by:
-
Dmitry Safonov authored
I think, it's more pretty to pass -DCONFIG_X86_* instead of all $DEFINES. That simplifies the statement and makes it more readable. Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Dmitry Safonov authored
Sorry for this typo, I should be more attentive. Fixes: commit ea523b183326 ("compel: shuffle skeleton a bit"). Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: -
Dmitry Safonov authored
Check if ELF header complements ELF magic in per-arch way. Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Dmitry Safonov authored
Split handle_elf() function from main.c to per-arch. Rename it to handle_binary not to cross-reference. Rename generic handle_elf to __handle_elf as with define not to litter namespace. Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Dmitry Safonov authored
I propose to change compel directory structure: - if we want support more arch's than x86/ppc66, it seems worth to add arch/ folder - move all sources from src/ folder up - to have headers and build additional object with CFLAGS for a symlink seems for me less hacky way than mess around with .c files cross-linking - I made handle-elf.h header for arch helpers code. I may named that just "elf.h", but that may confuse, as there are <elf.h> system header - I would like to drop those ELF_PPC64/ELF_X86_32/ELF_X86_64 defines and use CONFIG_X86_64 and whatnot After this patch compel directory become: compel/ ├── arch │ ├── ppc64 │ │ └── include │ │ └── handle-elf.h │ └── x86 │ └── include │ └── handle-elf.h ├── handle-elf-32.c -> handle-elf.c ├── handle-elf.c ├── include │ ├── piegen.h │ └── uapi │ ├── elf32-types.h │ ├── elf64-types.h │ └── types.h ├── main.c └── Makefile Note: temporary I make value32 and addend32 for compilation on arm/aarch64 Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Dmitry Safonov authored
Cc: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
-
Dmitry Safonov authored
With `-r` option relocation to parasite_service was not made on ARM: 0x76dbc018: bl 0x76dbc018 0xebfffffe (You may saw it with objdump also). This leaded to hang at "Putting tsock" message: (01.368297) ---------------------------------------- (01.368321) (01.368339) Collecting fds (pid: 13503) (01.368360) ---------------------------------------- (01.368535) Found 3 file descriptors (01.368564) ---------------------------------------- (01.368648) Dump private signals of 13503 (01.368708) Dump shared signals of 13503 (01.368761) Parasite syscall_ip at 0x10000 (01.369605) Set up parasite blob using memfd (01.369641) Putting parasite blob into 0x76cc5000->0x76e1f000 (01.369755) Dumping GP/FPU registers for 13503 (01.369818) Putting tsock into pid 13503 Link against native.lib.a which also fixes build for aarm64. Reported-by:
alex vk <avankemp@gmail.com> Reported-by:
long.wanglong <long.wanglong@huawei.com> Cc: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Christopher Covington <cov@codeaurora.org> Reviewed-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
-
Cyrill Gorcunov authored
https://github.com/xemul/criu/issues/148#issuecomment-211635122Signed-off-by:
-
Cyrill Gorcunov authored
In case of error don't re-close files already closed. https://github.com/xemul/criu/issues/148Reported-by:
-
Dmitry Safonov authored
It's included through "asm/restorer.h". Signed-off-by:
-
Dmitry Safonov authored
Signed-off-by:
-
Dmitry Safonov authored
Signed-off-by:
-
Dmitry Safonov authored
This will document that {get,set}_user_reg should be used only on initialized register set. Otherwise, after some code changes we may find ourself in situation when setting not inited user regs will set them for compatible register set: (is_native == false). Signed-off-by: -
Dmitry Safonov authored
Detect task's personality by the size of register set, returned by ptrace call with PTRACE_GETREGSET (more reliable). The same approach uses strace from 4.8 version: https://sourceforge.net/projects/strace/files/strace/4.8/Signed-off-by:
-
Dmitry Safonov authored
Introduced user_regs_struct32. Other changes mainly are reforming existing code to use the new register sets union. For protobuf images - reuse user_x86_regs_entry for both compatible and native tasks with enum in the beggining that describes register set type. That's better and simpler, than introducing a new 32-bit register set for compatible tasks. I tried to do this firstly with oneof keyword: https://github.com/0x7f454c46/criu/commit/499c93ae0e2b8ffb8c562f309bb046d77d6b07c0 But protobuf supports oneof keyword only from recent version 2.6.0, so I tried to rework it into enum + 2 register sets: https://github.com/0x7f454c46/criu/commit/aab4489bd4e0b1360b6e05614c2fce3ff2a52eb7 But that did not work either because restorer pie takes gpregs as thread_restore_args parameter and UserRegsEntry shouldn't contain pointers, but structure objects. This may be fixed by redefining UserRegsEntry not as typedef for UserX86RegsEntry, but containing needed objects, than treat it right for restorer - but that's more complicated that reusing user_x86_regs_entry. Signed-off-by:
-
Dmitry Safonov authored
Only parasite should be mode-depended, not restorer, as restorer will just switch to compatible mode with arch_prctl at the end and jump to 32-bit executable with sigreturn. So for parasite there are two targets: "native" and "compat", and one for restorer with the same name "restorer". It will result in parasite-native.o, parasite-compat.o and restorer.o objects. Pie build still may work with piegen or without it (gen-offset.sh). There are many FIXME in this patch, all them are in C code, that should be fixed to use compatible parsite when needed. Signed-off-by:
-
Dmitry Safonov authored
In code they yet use native parasite type, but in definition this parameter is not used (will be used at the next patch). Signed-off-by:
-
Dmitry Safonov authored
Signed-off-by:
-
Dmitry Safonov authored
Now compatible objects will be in $(obj)/compat/$(basename)-compat.o I can't use just $(obj)/compat/$(basename).o as basename for file will be the same as for native object, which wouldn't work by the reason of CFLAGS_$(F) in nmk-ccflags. So, I need different names for compatible/native objects. Because I don't want to make a mess in parent directories, I put this symlinks to compat/ dirs. This is how I came to that decision (even if I do not like it). Signed-off-by:
-
Dmitry Safonov authored
First pie library to use for compiling native pie. Signed-off-by:
-
Dmitry Safonov authored
Signed-off-by:
-
Dmitry Safonov authored
Impact: search sys-exec-tbl-32.c for compatible tasks. Rename task_in_compat_mode to arch_task_compatible and use it in find_syscall for 64-bit to check compatible task's syscall nr. It still will not execute syscall in 32-tasks, as we still do not have 32-bit pie (arch_can_dump_task will return false for these tasks). NOTE: be sure to `make mrproper` on criu directory before applying this patch, as before `criu/arch/x86/sys-exec-tbl.c` was autogenerated, it will make conflict if you try to apply this patch on dirty directory. Signed-off-by:
-
Dmitry Safonov authored
After uncommenting FIXME: It will add sc_exec_table_32 for compatible tasks to sys-exec-tbl.c Now it does: - add two different 32/64 syscall tables for cr-exec sys-exec-tbl-{64,32}. - add two different syscall headers syscall-{64,32}.h, that are included from more x86 generic syscall.h depending on -DCONFIG_X86_{32,64} option. - builds two different syscalls-{32,64}.built-in.o - for criu core files, that need SYS_memfd_create and other SYS_* __NR_* defines (currently kerndat.c and shmem.c), create simple syscall-codes.h that includes syscall-codes-64.h [Added after rebase on master] That way after apply, the compatible patch set will be simply able to bisect for regressions. Signed-off-by: -
Dmitry Safonov authored
Signed-off-by:
-
Cyrill Gorcunov authored
It's a hostprog so one target is enough, otherwise we're gitting double deps generation. Signed-off-by:
-
Cyrill Gorcunov authored
We don't need it actually. Signed-off-by:
-
Cyrill Gorcunov authored
The compel component is a replacement for several aspects of CRIU functionality: binary blobs generation for PIE parasite/restore code, and a library for parasite code injection and execution (to be implemented). In the commit we rather shuffle compel into own directory and use it for 1) Fetching cflags when compiling PIE blobs 2) Use its "piegen" functionality to generate blobs themselves. Signed-off-by:
-
Cyrill Gorcunov authored
Here we introduce actions: - "piegen" to generate blobs, which is used by criu already; - "cflags" and "ldflags" to print out options needed for compiler and linker when building compel compatible objects. We rather moved old "main" function body into piegen helper function and implement the rest of actions since they are one-liners. Note the usage uses new "compel" brand, but it's safe because we don't export anything yet. Signed-off-by: -
Cyrill Gorcunov authored
This will be needed to print out cflags and ldflags. Unused at moment. Signed-off-by:
-
Dmitry Safonov authored
Fixes the following error on travis-ci: CC arch/x86/syscalls/syscall32.o In file included from /usr/include/signal.h:28:0, from /home/travis/build/0x7f454c46/criu/criu/arch/x86/include/asm/types.h:5, from arch/x86/syscalls/syscall32.c:1: /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory # include <sys/cdefs.h> ^ Signed-off-by:
-
- 08 Mar, 2017 1 commit
-
-
Pavel Emelyanov authored
This is not a huge release. Some new stuff for Docker c/r and several bugs fixed. Signed-off-by:
-
- 07 Mar, 2017 1 commit
-
-
Pavel Emelyanov authored
The ipcns-shm images are buffered and contain raw dumps of memory contents. If the segment is huge, the bfd engine overflows and doesn't write data into image. This is not nice by itself, but huge images shouldn't use bfd to avoid double buffering. Also, in the future, this image should be fixed not to keep mem dumps in one image with object. https://github.com/xemul/criu/issues/287Signed-off-by:
-
- 06 Mar, 2017 5 commits
-
-
Kir Kolyshkin authored
A year ago this flag was removed, as parts of criu were build in sub-directories (i.e. by using make -C SUBDIR), and therefore paths printed by make were relevant to a SUBDIR rather than top source dir, which prevented tools like vim from jumping to a correct source file with with error (for more details, see commit XXXXXX "nmk: remove no-print-directory from MAKEFLAGS"). Now, as we have everything (except Documentation and test, which is rather minor) built from top source directory, we can finally add the flag back and enjoy cleaner output. Reviewed-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
-
Kir Kolyshkin authored
It was not working: > $ make DESTDIR=`pwd`/inst3 uninstall > UNINSTALL crit.1 > UNINSTALL criu.8 > UNINSTALL libcriu.so > UNINSTALL pkgconfig/criu.pc > UNINSTALL crit > /media/ts/kir/git/criu/scripts/nmk/scripts/build.mk:83: criu/arch/x86/Makefile: Not a directory > make[2]: *** No rule to make target 'criu/arch/x86/Makefile'. Stop. > Makefile:48: recipe for target 'criu/arch/x86/crtools.built-in.o' failed > make[1]: *** [criu/arch/x86/crtools.built-in.o] Error 2 > Makefile.install:49: recipe for target 'uninstall' failed > make: *** [uninstall] Error 2 This is a fix to commit 7a360484 ("build/make: return to make from top directory"). Reviewed-by:
-
Kir Kolyshkin authored
Our whole system of Makefiles are integrated from top to bottom, meaning: 1. The paths in sub-makefiles are relative to the top source dir. 2. Sub-makefiles are executed via make $(build)=<SUBDIR> <TARGET> For some reason, makefiles under lib/ are the exclusion. Let's fix it. Side effect: you can now build any individual target under lib/, for example, "make lib/c/libcriu.so" works. [v2: use the .FORCE, thanks to dsafonov@] Signed-off-by:
-
Kir Kolyshkin authored
Instead of removing everything by means of a few wildcards, let's properly generate the file names to be removed. [v2: fix a typo, thanks to dsafonov@] [v3: resend with a typo fixed for real, this time] Reviewed-by:
-
Andrei Vagin authored
If a pipe is inherited (external), it may be impossible to reopen it from a restored user namespace due to lack of permession, so in this case we have to reopen it via usernsd. https://github.com/opencontainers/runc/issues/1333Signed-off-by:
-
