It took a little time on travis (I didn't measure, just starred
at build and it added not visible delay for build).
But it will help to verify that compel works on all supported arches.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Now it has 4 new tests:
ok 4 - section table start oob (64-bit ELF)
ok 5 - too many sections in table (64-bit ELF)
ok 6 - strings section's header oob of section table (64-bit ELF)
ok 7 - strings section oob (64-bit ELF)
I.e, if we forget to test string section's header oob with the next diff:
>--- a/compel/handle-elf.c
>+++ b/compel/handle-elf.c
>@@ -122,7 +122,7 @@ static const char *get_strings_section(Ehdr_t *hdr, uintptr_t mem,
> pr_err("String section @%#zx size %#lx is out of [%#zx, %#zx)\n",
> addr, (unsigned long)secstrings_hdr->sh_size,
> mem, mem + size);
>- return NULL;
>+ return (void*)addr;
> }
>
> return (void*)addr;
It will yell with:
ok 1 - zero ELF header (64-bit ELF)
...
not ok 6 - strings section's header oob of section table (64-bit ELF), expected -4 but ret is -1
...
not ok 12 - strings section's header oob of section table (32-bit ELF), expected -4 but ret is -1
Should be more useful when I add relocations tests after all.
(but this seems for me useful too).
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Sorry for introducing that, but we need to force-rebuild implicit
rules on the level of main Makefile. All the sub-makefiles should
decide if the force-rebuilding target really needs a rebuild,
because they know it's dependencies.
Pattern-specific rules are implicit, so something like:
.PHONY: compel/% criu/% #...
will not work.
.FORCE target seems the simplest way to solve this
"going to submake on rebuild" problem.
But maybe there is more elegant proposal?
FWIW, before this patch:
[criu]$ make compel/compel
make[1]: Entering directory '~/tools/criu'
HOSTDEP compel/handle-elf-32.d
...
HOSTLINK compel/compel
make[1]: Leaving directory '~/tools/criu'
[criu]$ touch compel/main.c
[criu]$ make compel/compel
make: 'compel/compel' is up to date.
[criu]$ touch compel/Makefile
[criu]$ make compel/compel
make: 'compel/compel' is up to date.
After the patch:
[criu]$ touch compel/main.c
[criu]$ make compel/compel
make[1]: Entering directory '~/tools/criu'
HOSTDEP compel/main.d
HOSTCC compel/main.o
HOSTLINK compel/compel
make[1]: Leaving directory '~/tools/criu'
[criu]$ touch compel/Makefile
[criu]$ make compel/compel
make[1]: Entering directory '~/tools/criu'
HOSTDEP compel/handle-elf-32.d
...
HOSTLINK compel/compel
make[1]: Leaving directory '~/tools/criu'
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Well, I hope, I will not make integer promotion mistakes anymore:
> 6.3.1.1
> If an int can represent all values of the original type, the value
> is converted to an int; otherwise, it is converted to an unsigned int.
> These are called the integer promotions.48) All other types are
> unchanged by the integer promotions.
>>> CID 161317: (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "hdr->e_shentsize" with type
"unsigned short" (16 bits, unsigned) is promoted in
"hdr->e_shentsize * hdr->e_shnum" to type "int" (32 bits, signed),
then sign-extended to type "unsigned long" (64 bits, unsigned).
If "hdr->e_shentsize * hdr->e_shnum" is greater than 0x7FFFFFFF,
the upper bits of the result will all be 1.
96 size_t sec_table_size = hdr->e_shentsize * hdr->e_shnum;
>>> CID 161317: (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "hdr->e_shentsize" with type
"unsigned short" (16 bits, unsigned) is promoted in
"hdr->e_shentsize * hdr->e_shstrndx" to type "int" (32 bits, signed),
then sign-extended to type "unsigned long" (64 bits, unsigned).
If "hdr->e_shentsize * hdr->e_shstrndx" is greater than 0x7FFFFFFF,
the upper bits of the result will all be 1.
111 addr = sec_table + hdr->e_shentsize * hdr->e_shstrndx;
Fixes: #157
Fixes: commit 36664a3cabec ("compel: separate get_strings_section from
__handle_elf").
Reported-by: Coverity
Reported-by: Andrew Vagin <avagin@virtuozzo.com>
Cc: Andrew Vagin <avagin@virtuozzo.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Yet they only test for ELF header, but soon I'll add more of them.
It's build with
$ make test/compel/handle_binary
and test output is in TAP format:
$ ./test/compel/handle_binary
ok 1 - check zero ELF header
ok 2 - check non-supported ELF header
ok 3 - check non-relocatable ELF header
ok 4 - check zero ELF header
ok 5 - check non-supported ELF header
ok 6 - check non-relocatable ELF header
(here two runs for x86_64 and x86_32 ELF binaries)
I'm planning to integrate it with Travis, so we will be
sure that compel is properly working (as this tests doesn't need
any ns and may be run on qemu-static).
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>
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>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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: Dmitry Safonov <dsafonov@virtuozzo.com>
Reviewed-by: Christopher Covington <cov@codeaurora.org>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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:
499c93ae0e
But protobuf supports oneof keyword only from recent version 2.6.0,
so I tried to rework it into enum + 2 register sets:
aab4489bd4
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 <dsafonov@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
It's a hostprog so one target is enough,
otherwise we're gitting double deps generation.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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/287
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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 7a36048 ("build/make: return to make from top
directory").
Reviewed-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
