Compel - Revision history

Radostin: /* Using libcompel.a library */ fix typo

2018-08-29T14:43:23Z

Using libcompel.a library: fix typo

2017-09-28T08:46:57Z

2017-09-28T07:42:03Z

2017-07-13T12:55:58Z

2017-02-02T01:22:25Z

-p is now optional

2017-02-02T00:48:01Z

Compiling and packing: use modern compel, cut the crap

2016-12-08T21:38:19Z

Infecting: improve setup_c_header description

2016-12-08T21:14:29Z

Infecting: fix according to latest git

2016-12-08T21:11:45Z

Using libcompel.a library: fix according to the latest git

2016-11-28T10:01:40Z

@@ Line 42: / Line 42: @@
 === Using libcompel.a library ===
-Currently there is only one way to load the blob into victim task using libcompel.a, called ''c-header'' <ref>This is done for historical reasons, it was the most handy way to load [[parasite code]] by CRIU. In plans we have loading the .po ELF file itself</ref>. First you should make a header out of you .po file with the <code>hgen</code> action of compel tool:
+Currently there is only one way to load the blob into victim task using libcompel.a, called ''c-header'' <ref>This is done for historical reasons. It was the most handy way to load [[parasite code]] by CRIU. In plans we have loading the .po ELF file itself</ref>. First you should make a header out of your .po file with the <code>hgen</code> action of compel tool:
   compel hgen -f parasite.po -o parasite.h

@@ Line 85: / Line 85: @@
 * [[Compel/Usage_scenarios]]
 * [[Compel plugins]]
-* Examples of working code available [https://github.com/xemul/criu/tree/criu-dev/compel/test on github] <ref>Clone the repo, build the project by running <code>make</code>, then go to <code>compel/test/$test_name</code> directory and run <code>make</code> there. Running <code>spy</code> bynary runs the example. Then -- RTFS or talk to us on [https://lists.openvz.org/mailman/listinfo/criu criu@openvz.org] :)</ref>
+* Examples of working code available [https://github.com/checkpoint-restore/criu/tree/criu-dev/compel/test on github] <ref>Clone the repo, build the project by running <code>make</code>, then go to <code>compel/test/$test_name</code> directory and run <code>make</code> there. Running <code>spy</code> bynary runs the example. Then -- RTFS or talk to us on [https://lists.openvz.org/mailman/listinfo/criu criu@openvz.org] :)</ref>
 * Info about CRIU [[code blobs]] in which the same technology is used

← Older revision		Revision as of 07:42, 28 September 2017
Line 1:		Line 1:
−	'''Compel''' is a utility to execute arbitrary code in a context of a foreign process. Compel is part of CRIU, and its sources are available from [https://github.com/~~xemul~~/criu/tree/criu-dev/compel the criu-dev branch of CRIU repo, subdirectory compel].	+	'''Compel''' is a utility to execute arbitrary code in a context of a foreign process. Compel is part of CRIU, and its sources are available from [https://github.com/checkpoint-restore/criu/tree/criu-dev/compel the criu-dev branch of CRIU repo, subdirectory compel].

	The code to be executed is called '''parasite code'''. Once compiled with compel flags and packed, it can be executed in other task's context. Note the code is run in environment without glibc, thus it can not call the usual stdio/stdlib/etc. functions.		The code to be executed is called '''parasite code'''. Once compiled with compel flags and packed, it can be executed in other task's context. Note the code is run in environment without glibc, thus it can not call the usual stdio/stdlib/etc. functions.

@@ Line 44: / Line 44: @@
 Currently there is only one way to load the blob into victim task using libcompel.a, called ''c-header'' <ref>This is done for historical reasons, it was the most handy way to load [[parasite code]] by CRIU. In plans we have loading the .po ELF file itself</ref>. First you should make a header out of you .po file with the <code>hgen</code> action of compel tool:
-  compel hgen -f parasite.po -p parasite -o parasite.h
+  compel hgen -f parasite.po -o parasite.h
 Options meaning is the following:
 * <code>-f</code> tells which binary to turn into header
 * <code>-o</code> tells where to write the resulting header
 Once <code>parasite.h</code> file is ready, it should be included into the infecting program source code to be compiled with it.
@@ Line 73: / Line 72: @@
 with <code>ctl</code> as an argument. Here <code>''PREFIX''</code>
 is the same as the argument given to <code>-p</code> option
-to <code>compel hgen</code>.
+to <code>compel hgen</code>, and if not given, it is derived
 Second, when infecting a parasite one should specify the amount of threads it will mess with (1, if only the thread leader will be accessed) and the maximum size of the memory area shared between infecting task and parasite used for arguments/result passing.

@@ Line 26: / Line 26: @@
 </pre>
-Don't forget to put <code>compel/include/uapi/</code> directory into include paths.
+Then link the parasite binary. Include all the .o files needed.
 <pre>
-$ ld foo1.o foo2.o compel/plugins/std.built-in.o -T compel/arch/$ARCH/scripts/compel-pack.lds.S -o parasite.po
+$ ld $(compel ldflags) foo1.o foo2.o $(compel plugins) -o parasite.po
 </pre>

@@ Line 72: / Line 72: @@
 First, the <code>ctl</code> should be configured with the blob information. For that,
-you should call <code>''PREFIX''_setup_c_header()</code> function,
+you should call <code>''PREFIX''_setup_c_header()</code> function
-where <code>''PREFIX''</code> is the same as the argument given to
+with <code>ctl</code> as an argument. Here <code>''PREFIX''</code>
-<code>-p</code> option to <code>compel hgen</code>.
+is the same as the argument given to <code>-p</code> option
 Second, when infecting a parasite one should specify the amount of threads it will mess with (1, if only the thread leader will be accessed) and the maximum size of the memory area shared between infecting task and parasite used for arguments/result passing.